CI-CD流程设计#

标准流水线： Push → Build → Test → Package → Deploy-Staging → E2E → Deploy-Prod

工具链： Git(代码) → GitHub Actions/GitLab CI/Jenkins(引擎) → Maven+Docker(构建) → Harbor(镜像) → K8s+Helm(部署，或 Argo CD 做 GitOps 拉取式部署) → Prometheus(监控)

关键实践： 每次 commit 触发 CI / 测试覆盖率门禁 / 镜像 tag 用 git SHA / 生产部署需审批+灰度

CI/CD的核心目标是让代码从提交到上线全程自动化，减少人工介入和出错概率。标准流水线分几步：开发者Push代码后自动触发构建（Maven/Gradle编译），然后跑单元测试和代码质量门禁（比如覆盖率不低于80%），通过后Docker打包镜像并推送到Harbor，镜像tag用git SHA保证可追溯。接着自动部署到Staging环境跑集成测试和E2E测试，全部通过后生产发布需要审批加灰度。工具链方面，我们用的是GitLab CI做流水线引擎，Maven构建Java项目，Docker打包，Harbor存镜像，K8s+Helm做部署编排，Prometheus监控发布后的服务指标。几个关键实践：每次commit都触发CI保证持续集成，镜像不可变（同一个SHA对应唯一镜像），生产部署必须走灰度+回滚预案。

追问方向：

• “CI 和 CD 的区别是什么？”→ CI 是持续集成（代码合并后自动构建+测试），CD 分持续交付（自动到 Staging）和持续部署（自动到 Prod）；大多数团队做到持续交付，生产发布仍需审批
• “流水线失败了怎么排查？”→ 看 Pipeline 日志定位失败阶段：编译失败查依赖/语法、测试失败查用例、镜像推送失败查 Harbor 认证/磁盘空间；设置 Slack/钉钉通知第一时间告警
• “Jenkins 和 GitLab CI 怎么选？”→ 跟着代码托管走：代码在 GitLab 用 GitLab CI（.gitlab-ci.yml），在 GitHub 用 GitHub Actions（.github/workflows/*.yml，Marketplace 现成 Action 多），都与仓库原生集成、上手快；Jenkins 自托管、插件生态丰富、灵活度高，但要自己维护 Controller/Agent 和插件升级，适合已有存量或流水线高度定制、需内网离线的场景

易错点：

• ❌ 每个环境各自重新构建镜像——应该构建一次（Build once），同一个镜像（按 digest/SHA）逐级晋升 Staging→Prod，只换配置，否则测过的和上线的不是同一个产物
• ❌ 镜像 tag 用 latest——不可追溯、节点缓存可能导致拉到旧镜像，回滚也找不到明确版本
• ❌ 把密钥写进 .gitlab-ci.yml/Dockerfile——应放 CI 平台的 Secret/Variables 或 Vault，并在日志中屏蔽；镜像层里的密钥删了也能从历史层取出