CI/CD 与 DevOps 三

应用实践中：部署到开发/测试环境后 → 加入跑接口自动化环节

1. 实际流水线

plaintext

代码提交
  ↓
构建 build
  ↓
单元测试（可选）
  ↓
打包镜像
  ↓
【部署到开发环境】 先部署
  ↓
【接口自动化测试】 在这里跑
  ↓
测试通过 → 继续部署测试/预发/生产

2. 关键定位：接口自动化放在部署后，属于 CD 环节，不是 CI

• CI（持续集成）：代码层面，打包前 单元测试、代码检查、编译构建
• CD（持续交付）：环境层面，部署后 部署到开发环境 → 接口自动化、集成测试、系统测试

这里接口自动化 = 部署后测试，属于 CD 阶段的质量门禁。

3. 为什么这么做？

优点（企业真实考量）

1. 接口测试必须服务跑起来、接口能访问才能测
2. 开发环境最贴近真实运行环境，测的更准
3. 能验证：镜像没问题 + 部署脚本没问题 + 环境配置没问题
4. 单元测试只能测代码逻辑，测不了真实接口连通性
5. 真实接口自动化、全链路测试、数据库交互测试 → 真实、全面、环境验证

缺点

• 问题发现比 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   # 调用开发环境真实接口