应用实践中部署到开发/测试环境后 → 加入跑接口自动化环节1. 实际流水线plaintext代码提交 ↓ 构建 build ↓ 单元测试可选 ↓ 打包镜像 ↓ 【部署到开发环境】 先部署 ↓ 【接口自动化测试】 在这里跑 ↓ 测试通过 → 继续部署测试/预发/生产2. 关键定位接口自动化放在部署后属于 CD 环节不是 CICI持续集成代码层面打包前单元测试、代码检查、编译构建CD持续交付环境层面部署后部署到开发环境 → 接口自动化、集成测试、系统测试这里接口自动化 部署后测试属于 CD 阶段的质量门禁。3. 为什么这么做优点企业真实考量接口测试必须服务跑起来、接口能访问才能测开发环境最贴近真实运行环境测的更准能验证镜像没问题 部署脚本没问题 环境配置没问题单元测试只能测代码逻辑测不了真实接口连通性真实接口自动化、全链路测试、数据库交互测试 → 真实、全面、环境验证缺点问题发现比 CI 晚部署完才发现问题回滚成本更高速度慢流水线时间更长4.实际版 .gitlab-ci.ymlyamlstages: - build - unit_test # CI单元测试 - build_image - deploy_dev # 部署开发环境 - api_auto_test # 你们这里跑接口自动化 - deploy_test - deploy_prod # 构建 build: stage: build image: node:18 script: - npm install # 单元测试CI unit_test: stage: unit_test script: - npm run test # 构建镜像 build_image: stage: build_image ... # 部署开发环境 deploy_dev: stage: deploy_dev script: - ssh 部署到开发服务器 # 你们的接口自动化部署后执行 api_auto_test: stage: api_auto_test image: node:18 script: - echo 开始接口自动化测试开发环境 - npm run test:api # 调用开发环境真实接口
