别再死记硬背CICD概念了！用Jenkins+GitLab实战带你理解持续集成、交付、部署到底有啥区别

从零构建CICD流水线：用Jenkins+GitLab实战拆解持续集成、交付与部署的核心差异

每次听到"持续集成"、"持续交付"、"持续部署"这三个术语时，你是否也曾在心里默默画上等号？市面上大多数教程要么停留在概念堆砌，要么直接跳入技术细节，却很少真正揭示三者如何在实际流水线中层层递进。本文将带你用Jenkins和GitLab搭建一条完整的自动化流水线，在每个关键节点标注CI、CD的分水岭，让你在代码推送、镜像构建、环境部署的实操中，直观感受自动化程度如何逐步升级。

1. 环境准备与项目初始化

1.1 基础设施配置

在开始前需要准备以下基础组件：

• Jenkins 2.4+：作为流水线调度中枢
• GitLab 14.0+：代码仓库与触发源
• Docker 20.10+：环境容器化工具
• Kubernetes集群（可选）：用于生产环境部署

安装Jenkins时务必包含以下插件：

# 必要插件列表 gitlab-plugin pipeline docker-workflow kubernetes

1.2 示例项目结构

我们以一个Python Flask应用为例，其仓库结构如下：

├── app/ │ ├── __init__.py │ └── routes.py ├── tests/ │ ├── unit/ │ └── integration/ ├── Dockerfile ├── Jenkinsfile └── requirements.txt

提示：Jenkinsfile将作为流水线定义文件，建议放在项目根目录与代码同步维护

2. 持续集成（CI）实战：代码提交即构建

2.1 自动化构建触发

在Jenkins中创建多分支流水线项目，配置GitLab仓库地址后，任何推送到feature/*分支的代码都会触发以下流程：

pipeline { agent any stages { stage('Checkout') { steps { git branch: '${BRANCH_NAME}', url: 'git@gitlab.com:yourrepo/ci-demo.git' } } stage('Unit Test') { steps { sh 'python -m pytest tests/unit --cov=app' } } stage('Build Image') { steps { script { docker.build("ci-demo:${env.BUILD_ID}") } } } } }

2.2 CI的核心特征

• 高频集成：开发者每天可提交多次代码
• 快速反馈：单元测试在3分钟内完成
• 质量门禁：代码覆盖率低于80%自动失败

下表展示传统模式与CI的对比：

注意：此时流水线仅运行到镜像构建阶段，尚未涉及任何环境部署

3. 持续交付（CD）进阶：预生产环境就绪

3.1 交付流水线扩展

在CI的基础上增加新阶段，将通过测试的镜像推送到预生产环境：

stage('Deploy to Staging') { when { branch 'main' } steps { kubernetesDeploy( configs: 'k8s/staging.yaml', kubeconfigId: 'k8s-credentials' ) } }

3.2 关键交付节点

1. 人工审批介入：需手动点击确认才会部署到生产环境
2. 环境一致性：使用相同Docker镜像在不同环境部署
3. 验收测试：在预生产环境运行集成测试

# 预生产环境测试命令示例 kubectl exec -it staging-pod -- python -m pytest tests/integration

3.3 CI vs CD分界线

• 持续集成：到"镜像构建成功"即完成
• 持续交付：延伸至"预生产环境可用"
• 核心差异：交付阶段需要完整的环境配置管理

4. 持续部署（CD）终极形态：全自动发布

4.1 部署自动化改造

移除人工审批环节，配置自动金丝雀发布策略：

# production-rollout.yaml apiVersion: apps/v1 kind: Deployment metadata: name: ci-demo spec: strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 0 template: spec: containers: - name: app image: your-registry/ci-demo:${VERSION} readinessProbe: httpGet: path: /health port: 5000

4.2 监控与回滚

部署后自动执行：

1. 流量逐步切量（10% → 50% → 100%）
2. 实时监控错误率（Prometheus + Grafana）
3. 异常时自动回滚到上一版本

stage('Auto Rollback') { steps { timeout(time: 5, unit: 'MINUTES') { waitUntil { def metrics = getPrometheusMetrics('error_rate') return metrics < 0.01 // 错误率阈值1% } } script { if(currentBuild.result == 'UNSTABLE') { rollbackDeployment() } } } }

5. 三阶段技术对比与选型建议

5.1 自动化程度光谱

通过下表清晰对比三个阶段的特性：

5.2 渐进式实施路线

根据团队成熟度推荐分阶段实施：

1. 初级阶段：先实现CI（每日构建+测试）
2. 中级阶段：添加CD交付（预生产验证）
3. 高级阶段：全自动部署（需完善监控体系）

关键提示：不要盲目追求持续部署，医疗、金融等行业可能永远需要人工审批环节

6. 真实场景下的避坑指南

在实施过程中会遇到一些典型问题：

• 环境漂移：用Docker镜像而非脚本保证环境一致
• 测试不可靠：避免flakey tests（时好时坏的测试）
• 流水线性能：大项目建议采用分布式执行器

# 排查测试不稳定的实用命令 pytest --flake-finder --count=5 tests/

经过三个月的实践验证，最容易被低估的是监控覆盖率。我们曾因未监控数据库迁移脚本，导致自动部署后出现数据兼容问题。现在会在部署后立即运行：

# 数据兼容检查脚本示例 def check_schema_compatibility(): old_conn = get_legacy_db_connection() new_conn = get_new_db_connection() assert compare_schemas(old_conn, new_conn)