应用实践中：部署到开发/测试环境后 → 加入跑接口自动化环节
1. 实际流水线
plaintext
代码提交 ↓ 构建 build ↓ 单元测试（可选） ↓ 打包镜像 ↓ 【部署到开发环境】 先部署 ↓ 【接口自动化测试】 在这里跑 ↓ 测试通过 → 继续部署测试/预发/生产2. 关键定位：接口自动化放在部署后，属于 CD 环节，不是 CI
- CI（持续集成）：代码层面，打包前单元测试、代码检查、编译构建
- CD（持续交付）：环境层面，部署后部署到开发环境 → 接口自动化、集成测试、系统测试
这里接口自动化 = 部署后测试，属于 CD 阶段的质量门禁。
3. 为什么这么做？
优点（企业真实考量）
- 接口测试必须服务跑起来、接口能访问才能测
- 开发环境最贴近真实运行环境，测的更准
- 能验证：镜像没问题 + 部署脚本没问题 + 环境配置没问题
- 单元测试只能测代码逻辑，测不了真实接口连通性
- 真实接口自动化、全链路测试、数据库交互测试 → 真实、全面、环境验证
缺点
- 问题发现比 CI 晚，部署完才发现问题，回滚成本更高
- 速度慢，流水线时间更长
4.实际版 .gitlab-ci.yml
yaml
stages: - 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 # 调用开发环境真实接口
