CI/CD 实战：如何自动化打包、发布与部署

一、为什么打包、发布、部署必须自动化

不少团队仍在使用“人肉流水线”发版：本地打包、远程登录服务器、手动上传文件、停服务、替换产物、重启、再逐一验证……整个链条完全依赖操作者的记忆和经验。这种模式的缺陷非常明显：

• 重复劳动，效率低下：每次发版步骤几乎相同，却要占用工程师大量时间，发版频率越高，浪费越严重；
• 易漏易错：少改一个配置、忘清一个缓存，都可能直接引发线上故障；
• 环境不一致：“本地能跑、测试正常、一到生产就出问题”，根源通常是构建与运行环境无法复现；
• 不可追溯：线上运行的到底是哪个版本？何时发布？由谁操作？缺乏记录导致排查困难；
• 心理负担重：每次上线都提心吊胆，团队因此倾向减少发版频率，反过来又拉长了问题的暴露周期。

持续集成/持续交付/持续部署（CI/CD）正是针对上述问题的工程化解法。按照业界普遍认可的理解：持续集成强调频繁合入代码并自动构建、自动测试；持续交付保证代码随时处于可发布状态；持续部署则进一步把通过验证的版本自动发布到目标环境。落地时，通常选择一个开源 CI/CD 服务端作为“自动化中枢”——这类工具生态成熟、插件丰富，基本可以覆盖所有自动化构建与部署需求。虽然初次配置有一定门槛，但一旦搭好，每次向仓库 push 代码都能自动触发构建与部署，长期收益远高于一次性投入。

二、整体流程设计：把“上线”拆成三个可控阶段

一套规范的自动化交付流程，本质上把“上线”拆解为三个边界清晰、各自可验证的阶段：

1. 打包（Build & Package）：拉取源码 → 编译 → 运行单元测试 → 产出制品（二进制包、压缩包或容器镜像）。制品命名建议包含版本号、构建号与提交哈希，例如 demo-app-1.4.2+build.128.a1b2c3d.tar.gz，确保任何一次部署都能对应到明确的代码版本。
2. 发布（Release）：将制品归档到平台或制品库，形成可追溯的版本序列。历史制品保留多长时间、按什么策略清理，都应事先约定。
3. 部署（Deploy）：把制品传输到目标环境，执行“停旧换新”、健康检查，失败则自动回滚。

整条链路可以用一张示意流程表达：

git push → 自动触发构建 → 编译 + 单元测试 → 产出制品 → 归档制品
        → 自动部署测试环境 → 自动化/人工验证 → （生产环境审批）
        → 部署生产环境 → 健康检查 → 失败自动回滚 → 通知团队

三、环境准备：资源规划与基础依赖

1. 服务器规格建议

• 内存：2GB 可以跑起最小实例，但构建任务并发较多时建议 4GB 以上，否则容易出现卡死；可适当配置 swap 作为兜底；
• CPU：2 核起步，多人共用或流水线较多时建议 4 核；
• 磁盘：构建产物、日志、依赖缓存都会持续占用空间，建议 40GB 起步，并建立定期清理机制；
• 网络：选择网络稳定、对团队成员延迟较低的节点，方便日常访问控制台与拉取代码。

2. 系统初始化

以主流 Linux 发行版（使用 apt 包管理器）为例，先完成系统更新：

sudo apt update && sudo apt upgrade -y

3. 安装运行时环境（JDK）

多数开源 CI/CD 服务端基于 JVM 生态构建，需要预先安装 JDK，建议选择 11 或 17 等长期支持（LTS）版本，并固定版本避免漂移：

sudo apt install -y default-jdk
java -version

4. 安装 Git

sudo apt install -y git
git --version

5. 容器引擎（可选）

如果项目需要以容器镜像方式交付，还应安装发行版仓库提供的容器引擎并设置开机自启，同时将执行构建的账号加入容器用户组，避免流水线因权限不足而失败：

# 安装并启用容器引擎（服务名以所用引擎文档为准）
sudo systemctl enable --now <容器引擎服务名>
# 将构建执行账号加入容器用户组
sudo usermod -aG <容器用户组> $USER

四、搭建 CI/CD 服务端：安装、启动与初始化

1. 添加软件源并安装

该类服务端一般不在发行版默认软件源中，标准做法是“导入官方签名密钥 → 添加软件源 → 更新索引 → 安装”（具体地址以所选工具官方文档为准）：

# 导入签名密钥
curl -fsSL <官方密钥地址> | sudo tee /usr/share/keyrings/ci-keyring.asc > /dev/null
# 添加软件源
echo "deb [signed-by=/usr/share/keyrings/ci-keyring.asc] <官方源地址> binary/" | sudo tee /etc/apt/sources.list.d/ci.list > /dev/null
# 更新索引并安装
sudo apt update
sudo apt install -y ci-server

通过 signed-by 指定密钥，既能保证软件包来源可信，也便于后续通过包管理器平滑升级。

2. 启动服务并设置开机自启

sudo systemctl start ci-server
sudo systemctl enable ci-server
sudo systemctl status ci-server

确认服务处于 running 状态后即可进行下一步。

3. 放行访问端口

服务端默认监听 8080 端口，需要在防火墙或云安全组中放行 8080/TCP。生产环境建议仅对办公网段或堡垒机开放，避免管理控制台直接暴露在公网。

4. 首次初始化

• 浏览器访问 http://服务器IP:8080；
• 按页面提示，到服务器上指定的数据目录读取初始管理员密码，完成解锁；
• 选择安装推荐插件，或按需最小化安装以缩短初始化时间；
• 创建管理员账号并确认实例访问地址；
• 建议立即配置定期备份（数据目录与任务定义），有条件的团队可以采用“配置即代码”的方式，把流水线定义纳入代码仓库统一管理。

五、配置打包流水线：从拉代码到出制品

1. 源码管理

新建任务时优先选择“流水线”类型，便于将构建过程版本化、可审计。配置仓库地址时，凭据（用户名密码或 SSH 私钥）必须走平台内置的凭据管理，严禁明文写入任务配置；同时明确分支策略，例如仅构建 main 分支与 release/* 分支。

2. 触发方式：轮询 vs Webhook

• 轮询（Poll SCM）：定时检查仓库是否有变更，实现简单，但存在延迟且会产生空跑；
• Webhook：代码托管平台在收到 push 事件后主动回调 CI 服务端，秒级触发，是推荐方案；
• 此外可保留少量定时任务，用于夜间全量回归测试。

3. 构建步骤与制品归档

构建步骤建议封装为中性脚本，保证本地与构建机行为一致：

make deps      # 还原依赖
make test      # 单元测试，失败即终止
make package   # 打包产出制品

构建产物统一归档到平台或推送至制品库，做到“任何一次上线都能追溯到明确版本”。特别强调：测试失败就是失败，绝不允许跳过测试继续打包。

六、发布与部署：让上线变成可重复的脚本

1. 部署目标机准备

• 建立专用部署账号，仅授予应用目录与对应服务的最小权限，使用密钥登录；
• CI 服务端通过 SSH 或部署代理与目标机通信；
• 应用以系统服务方式托管，统一 start/stop/健康检查入口。

2. 部署脚本设计要点

核心原则是：目录化发布 + 软链切换 + 健康检查 + 失败回滚。参考示例：

#!/usr/bin/env bash
set -euo pipefail
APP_DIR="/opt/demo-app"
PKG="$1"
RELEASE="$(date +%Y%m%d%H%M%S)"
# 1. 每次发布独立目录，天然支持回滚
mkdir -p "$APP_DIR/releases/$RELEASE"
tar -xzf "$PKG" -C "$APP_DIR/releases/$RELEASE"
# 2. 停止旧服务，切换软链指向新版本
systemctl stop demo-app || true
ln -sfn "$APP_DIR/releases/$RELEASE" "$APP_DIR/current"
# 3. 启动并做健康检查
systemctl start demo-app
for i in $(seq 1 10); do
  if curl -fsS http://127.0.0.1:9000/health >/dev/null; then
    echo "deploy success: $RELEASE"
    exit 0
  fi
  sleep 3
done
# 4. 健康检查失败：软链回滚到上一版本
echo "health check failed, rolling back"
systemctl stop demo-app
PREV="$(ls -1d "$APP_DIR/releases/"*/ | sort | tail -2 | head -1)"
ln -sfn "$PREV" "$APP_DIR/current"
systemctl start demo-app
exit 1

几个设计点值得展开：目录化发布让“回滚”退化为一次软链切换，秒级完成；健康检查不能只看进程是否拉起，必须探测真实业务接口；set -euo pipefail 确保任何一步出错立即中断，避免带病部署。

3. 容器化部署（进阶）

若采用容器交付，流水线中完成镜像构建 → 推送至镜像仓库 → 目标机拉取新镜像 → 滚动重启。其优势在于环境一致性强、依赖全部打包进镜像，回滚只需切换镜像标签；多实例场景建议配合容器编排平台实现滚动或灰度发布。

4. 环境分层与审批

按“开发 → 测试 → 预发 → 生产”逐级推进；生产部署设置人工审批卡点，防止误发布；同一套部署脚本通过参数区分环境，配置外置、不硬编码。

七、安全与稳定性最佳实践

• 凭据管理：全部收口到平台凭据库或密钥管理服务，并定期轮换；
• 权限最小化：按角色分配任务与视图权限，生产操作全程留痕；
• 资源控制：限制同时构建的并发数，避免内存打满导致卡死；构建机与生产目标机之间做好网络隔离；
• 日志与告警：保留构建与部署日志，失败时通过邮件或 IM 群机器人及时通知；
• 磁盘治理：定期清理历史构建产物、旧镜像与工作空间，防止磁盘写满引发服务异常；
• 备份演练：定期备份服务端数据目录与流水线定义，并实际演练恢复流程。

八、常见问题排查

• 服务频繁卡死：优先检查内存占用，升配或限制并发构建数，必要时增加 swap；
• 页面无法访问：确认 8080 端口已在防火墙/安全组放行，且服务处于运行状态；
• 拉取代码失败：检查凭据是否过期、部署密钥是否具备仓库读取权限；
• 部署后服务起不来：查看系统服务日志与应用日志，确认配置文件路径、环境变量与端口占用；
• 磁盘告警：清理旧制品、旧镜像与构建历史。

九、结语

打包、发布、部署的自动化，本质是把“依赖个人经验的人肉操作”沉淀为“任何人都能执行、可重复、可追溯的流水线”。环境准备 → 服务搭建 → 流水线配置 → 脚本化部署 → 健康检查与回滚，五个环节一次到位后，团队就能获得 push 代码即自动交付的流畅体验。若在云上落地，还可以结合云平台提供的代码托管、容器服务、制品库、监控告警等通用产品能力（例如百度智能云的相关产品矩阵），进一步降低自建与长期运维成本，让团队把精力真正集中在业务代码本身。