在现代软件开发中，CI（持续集成） 和 **CD（持续交付/持续部署）** 是通过自动化流程实现快速、可靠交付的核心实践。以下是基于权威公开资料整理的完整流程与关键要点：
一、CI/CD 的基本概念区分
- **持续集成（CI）**：开发人员频繁将代码提交到共享主干，每次提交自动触发构建、单元测试、代码质量检查等，确保新代码与现有代码兼容。
- 持续交付（CD） ：在 CI 基础上，自动将通过测试的代码部署到预生产环境（如测试、预发），但生产部署需人工确认。
- 持续部署（CD） ：更进一步，无需人工干预，代码通过所有自动化测试后自动发布到生产环境 6。
当前主流企业多采用"持续交付"模式（保留人工审核），仅高迭代互联网公司（如电商、社交平台）会采用"持续部署" 6。
**二、标准 CI/CD 流程（共 8 步）**
-
代码提交
开发基于功能分支（如
feature/xxx）开发，完成后提交 MR/PR（合并请求），经代码评审后合并到主干（如main或develop）6。 -
触发流水线
代码合并后，Git 仓库（如 GitHub/GitLab）通过 Webhook 自动触发 CI/CD 工具（如 Jenkins、GitLab CI）6。
-
拉取代码 & 环境准备
CI 工具从代码仓库拉取最新代码，并准备构建环境（如 JDK、Maven、Node.js 等）6。
-
编译与打包
执行构建命令（如
mvn clean package），生成可执行制品（如 JAR/WAR 包或 Docker 镜像）6。 -
自动化质量检测
- 单元测试：运行 JUnit、Pytest 等，验证单个模块功能。
- 集成测试：使用 Postman、TestNG 验证服务间调用。
- 代码质量扫描：通过 SonarQube 检查代码规范、漏洞、重复率等。
- **安全扫描（SAST）**：使用 SonarQube、Veracode 等工具检测安全风险 1。
若任一环节失败，立即终止流程并通知开发者 6。
-
制品固化与存储
构建产物被打上唯一版本标签（如基于 Git Commit ID），推送到制品仓库（如 Nexus、Harbor、Docker Registry）6。
-
部署到预生产环境
- 自动部署至测试/预发环境。
- 执行冒烟测试、UAT（用户验收测试）6。
-
**生产发布（分两种模式）**
- 持续交付 ：人工确认后手动触发生产部署，常采用金丝雀发布 或蓝绿部署降低风险 6。
- 持续部署：完全自动化，预发验收通过后自动发布到生产（适用于高成熟度团队）6。
三、常用工具链
| 阶段 | 工具示例 |
|---|---|
| 版本控制 | Git、GitHub、GitLab、Gitee |
| CI/CD 平台 | Jenkins、GitLab CI、CircleCI、GitHub Actions |
| 构建工具 | Maven、Gradle、npm、Make |
| 测试框架 | JUnit、Selenium、Cypress、JMeter |
| 制品仓库 | Nexus、Harbor、Docker Hub |
| 容器化 | Docker、Kubernetes |
| 监控反馈 | Prometheus、Grafana、Sentry |
示例 GitLab CI 配置（
.gitlab-ci.yml）10：
stages:
- build
- test
- deploy
build:
stage: build
script: mvn clean package
test:
stage: test
script: mvn test
deploy:
stage: deploy
script: docker push myapp:$CI_COMMIT_SHA四、关键优势
- 快速反馈：问题在提交后几分钟内暴露，修复成本低 4。
- 减少人为错误：自动化替代手工操作，提升稳定性 3。
- 高频发布：支持每日多次部署，加速业务迭代 6。
- 环境一致性：通过容器化和配置即代码，避免"在我机器上能跑"问题 10。