适用场景

CI/CD 的价值是"减少人为失误"：手工打包、手工上传、手工改配置，每一步都可能出错，而且无法复现。

配置步骤（GitLab CI 流水线）

stages: [build, test, scan, deploy]
build:
  stage: build
  script:
    - docker build -t registry.example.com/app: .
    - docker push registry.example.com/app:
scan:
  stage: scan
  script: trivy image --severity HIGH,CRITICAL registry.example.com/app:
deploy:
  stage: deploy
  script: kubectl set image deploy/app app=registry.example.com/app:
  only: [main]

关键参数与建议

  • 环境隔离：开发/测试/预发/生产，配置与密钥分离管理
  • 流水线阶段化：构建 → 单测 → 扫描 → 制品 → 部署 → 验证
  • 制品唯一版本（提交号或时间戳），可追溯、可回滚
  • 部署采用滚动或蓝绿，避免全量重启
  • 生产发布需要审批与变更记录（合规要求）

容易踩的坑

  • Runner 权限过大（能操作生产集群）
  • 变量未做保护，密钥在日志里被打印
  • 未做制品扫描，高危漏洞直接上线

验证与巡检

# 验证：流水线各阶段成功、制品可拉取、部署后健康检查通过
  • 巡检：Runner 权限最小化、变量受保护、扫描阶段生效

小结

CI/CD 的落地顺序：先把"构建 + 制品 + 手工部署到测试"自动化，再逐步做到生产自动发布。一步到位往往失败。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。