一、CI/CD基础概念：持续集成、持续交付、持续部署

大家好，我是老张。今天咱们聊聊CI/CD这仨词——持续集成、持续交付、持续部署。说实话，我刚入行那会儿也傻傻分不清，总觉得差不多。后来踩过坑、吃过亏，才慢慢摸出门道。嗯，今天我用大白话给你讲透。

1.1 持续集成（Continuous Integration，CI）

持续集成，说白了就是：开发人员频繁地把代码合并到主干，每次合并都自动跑构建和测试。目标？尽早发现集成问题，别等一堆代码攒到上线前才合并，那会儿想修bug都来不及了。

我记得2015年带一个电商项目，团队20来人，每人每天至少提交1~2次代码。一开始大家习惯各自在自己的分支上闷头开发，一周才合一次。结果每次合并都出冲突，测试跑一晚上，第二天发现一堆红——那个酸爽。后来我们强制推行CI，规定每小时必须往主干合一次，出了问题立刻修。你猜怎么着？上线前的问题量直接降了60%。

CI的核心流程其实很简单：

1. 开发 push 代码到主仓库
2. 自动化触发构建（编译、打包）
3. 运行单元测试、集成测试
4. 生成测试报告和构建产物
5. 反馈结果给团队（绿灯/红灯）

# 一个简单的 CI 脚本示例（Jenkins Pipeline 片段）
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Build') {
            steps { sh 'mvn clean compile' }
        }
        stage('Unit Test') {
            steps { sh 'mvn test' }
        }
        stage('Package') {
            steps { sh 'mvn package' }
        }
    }
    post {
        success { echo 'CI 通过！' }
        failure { echo 'CI 失败，请立即检查。' }
    }
}

1.2 持续交付（Continuous Delivery，CD）

持续交付是在CI的基础上，把构建好的产物自动部署到类似生产的环境（比如预发布、测试环境），确保任何一次构建都能随时发布上线。说白了，就是让软件永远处于“可发布”状态。

你想想看，如果CI跑完，你还需要手工去部署服务器、配置参数、跑迁移脚本……这就不叫持续交付。持续交付应该是：点一下按钮，或者直接自动触发，流程走完就能上线。当然，要不要真正上线，还得人决定——这就是交付和部署的区别。

我经历过一个项目，团队花了两周把CI搭好了，但每次发版还得运维手工改配置文件，动不动就配错端口。后来我们引入持续交付流水线，把环境配置、数据库迁移都自动化了，再也没出过类似问题。

1.3 持续部署（Continuous Deployment，Continuous Deployment）

持续部署比持续交付更进一步：所有通过自动化测试的变更，自动部署到生产环境。没有人工干预，真正意义上的“最后一公里”也自动化了。

说实话，持续部署对测试的信任要求非常高。我待过一家金融科技公司，他们只敢对非核心模块做持续部署，核心交易系统还是走手动审批。为什么？因为生产环境出了问题就是钱啊。不过像一些社交平台、SaaS产品，每周上百次部署都是常事。

以下表格可以帮你快速区分这三兄弟：

概念	自动构建+测试	自动部署到类生产	自动部署到生产	人工审批
持续集成	✓	✗	✗	N/A
持续交付	✓	✓	✗	需要
持续部署	✓	✓	✓	不需要

1.4 现代软件开发为什么离不开 CI/CD？

我自己的经历告诉我，没有CI/CD的团队就像开手动挡的赛车——不是不能赢，但很累。现代软件有几个特点：

• 节奏快：两周一个迭代，每天几十次提交
• 依赖多：微服务、第三方库、配置中心，牵一发而动全身
• 质量要求高：出bug可能直接扣钱、丢客户

这时候，CI/CD的价值就出来了——它能让你在短时间内获得高质量反馈。我记得曾有个项目，上线前一天发现数据库索引漏了，手工跑脚本改可能会阻塞。但我们有自动化迁移+回滚流水线，一条命令就搞定了，前后不到10分钟。

1.5 一张图看懂 CI/CD 体系

这张图你可以看到：CI/CD不是孤立的工具链，而是一套从开发到交付的价值流。每次提交代码都触发自动化流水线，每一步都为你节省时间、降低风险。