从手动部署到自动化交付：用华为云 CodeArts 流水线把上线时间压缩到 10 分钟

一、痛点：每个周五晚上都在重复的部署动作

很多小团队的开发流程是这样的：代码写完，本地跑通，打个压缩包，登录服务器，备份旧版本、上传新版本、重启服务、手动验证。整个过程顺利的话 20 分钟，不顺利的话——上传中断、配置漏改、服务起不来——周五晚上就交代进去了。

我经历过最狼狈的一次是配置文件里的数据库地址忘了从测试环境改回生产环境，上线后用户反馈数据"丢了一半"，排查半小时才发现写错了库。这类问题的共同点是：它们都是人手执行重复操作时必然出现的失误，而不是技术水平问题。

解决思路很简单：把"构建、检查、部署"这些固定动作交给流水线，人只负责写代码和点一次"执行"。这篇文章记录我用华为云 CodeArts 流水线把一个 Web 应用从手动部署改造为自动化交付的完整过程，改造后单次上线从 20 分钟压缩到 10 分钟以内，且过程中可以随时回退。

二、整体思路：四个阶段串成一条流水线

CodeArts 是华为云的一站式软件开发平台，其中"流水线"服务支持把多个任务编排成一条自动执行的链路。我给项目设计的流水线共四个阶段：

代码提交 (GitCode / CodeArts 代码仓)
      │
      ▼
┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
│  1. 拉取代码  │ → │  2. 构建产物  │ → │ 3. 质量检查  │ → │ 4. 部署发布  │
│   源码阶段   │   │  编译+打包    │   │  单元测试    │   │  上传+重启   │
└─────────────┘   └─────────────┘   └─────────────┘   └─────────────┘

• 阶段 1（源码）：流水线触发时从代码仓拉取指定分支，我配置为主分支有合并时自动触发；
• 阶段 2（构建）：执行编译打包，产出可部署的制品（比如 Jar 包或前端 dist）；
• 阶段 3（检查）：跑单元测试和代码静态检查，任何一项失败则流水线终止，坏代码到不了服务器；
• 阶段 4（部署）：把制品上传到服务器并重启服务，失败可一键回退到上一版本。

这个结构的关键价值在于"门禁"：阶段 3 挡住了绝大多数带伤上线，阶段 4 的版本化管理让回退成本接近于零。

三、动手实践：从零搭一条流水线

3.1 准备工作

需要提前准备三样东西：

1. 一个 CodeArts 项目（控制台创建，选"Scrum"或"看板"模板都可以，流水线功能与模板无关）；
2. 代码托管在 CodeArts Repo 或已关联的 GitCode 仓库；
3. 部署目标（我是一台 Flexus 云服务器，部署一个 Spring Boot 应用 + Nginx 静态资源）。

3.2 创建流水线并编排阶段

在项目左侧菜单进入"流水线"→“新建流水线”，选择空白模板后进入可视化编辑器。CodeArts 的编排方式是"阶段 → 任务 → 步骤"三级结构，每个阶段里可以拖入任务，任务下再配置具体步骤。

阶段 1：源码

添加"代码源"任务，选择我的 Repo 仓库，分支 master，触发方式开启"事件触发 → 合并请求合入"。

阶段 2：构建

添加"执行构建任务"前需要先在"编译构建"服务里创建一个构建任务。以 Maven 项目为例，核心步骤是：

# 构建任务里的自定义命令（简化版）
mvn clean package -Dmaven.test.skip=false
# 单测结果会被收集为报告
tar -czf app-$TIMESTAMP.tar.gz target/*.jar

构建产物会自动归档到制品库，每个版本都有唯一编号——这是后面能一键回退的基础。

阶段 3：检查

添加"代码检查"和"测试"任务。我在代码检查里开启了基础的门禁规则集（代码风格、空指针风险、日志规范），单元测试则直接复用构建阶段跑出的报告。这里有个实用配置：质量门禁设为"严重问题数 = 0 才放行"，宁可流程慢一点，也不让明显有问题的代码流向生产。

阶段 4：部署

先在"部署"服务里创建部署应用，目标主机填 Flexus 服务器的 IP 和凭据（需要在服务器上安装 Agent 并放行安全组端口）。部署步骤我拆成四步：

# 1. 停服
systemctl stop myapp || true
# 2. 备份当前版本
cp /opt/myapp/app.jar /opt/myapp/backup/app-$(date +%F-%H%M).jar
# 3. 拉取新制品（部署服务会自动传输，这里示意）
mv /tmp/upload/app.jar /opt/myapp/app.jar
# 4. 起服并做健康检查
systemctl start myapp
curl -sf http://127.0.0.1:8080/actuator/health | grep UP

健康检查通过才标记部署成功，这一步很重要——服务"启动命令执行了"和"真正能对外服务"是两回事。

3.3 串起来跑一次

四个阶段编排完成后保存流水线，手动点一次"执行"验证。第一次执行几乎必然失败，我的三次失败原因分别是：构建节点 Maven 依赖下载超时（换了华为云镜像源解决）、部署 Agent 安全组端口没放行、健康检查接口需要鉴权导致 curl 返回 401。逐项修完后全流程跑通。

四、改造前后的对比

最直观的变化是心理层面的：以前发版像拆盲盒，现在合并代码后去倒杯水，回来看流水线状态，绿色即完成。

五、踩坑与复盘

坑 1：流水线越早接入越省事。 我是在项目已经跑了半年后才改造的，构建脚本里散落着本地路径依赖和手工参数，规整这些花了两个晚上。新项目建议第一天就上流水线。

坑 2：门禁阈值别一刀切。 初期我把所有级别的问题都设为阻断，结果第一条流水线红了一周，团队抵触情绪很大。后来只对"严重"级别阻断、其他仅提示，流程才顺畅起来。门禁的意义是挡住大问题，不是追求零告警。

坑 3：部署脚本的幂等性。 停服、备份、覆盖、起服这四步，任何一步失败重跑时都必须能安全重来。比如 systemctl stop myapp || true 里的 || true，就是防止服务本来就没启动时脚本报错中断。

坑 4：制品版本号要可追溯。 早期我用时间戳命名制品，回退时要在服务器目录里翻半天。改成构建流水线统一编号后，"回退到上一个成功版本"变成流水线的一个选项，不需要人参与。

坑 5：别忘了流水线自身的权限。 流水线配置里藏着部署凭据，务必把项目成员权限收紧到"执行者"而非"管理者"，避免凭据被随意导出。

六、写在最后

这次改造的核心收获不是工具本身，而是一个观念：自动化交付的价值 = 节省的时间 × 避免的事故，后一项往往比前一项值钱。CodeArts 流水线对个人开发者和轻量团队很友好——基础编排免费额度足够日常使用，且与华为云的代码托管、编译构建、部署服务天然打通，不需要在多个工具间搬运配置。

如果你也有一个"每次上线都靠人肉"的项目，建议从最小可用版本开始：只编排"拉代码 → 构建 → 部署"三个阶段，跑通后再逐步加门禁和测试。一旦体会到"合并即上线、失败可回退"的确定感，就再也回不去了。

接下来我计划给这条流水线补充两个能力：一是把 Nginx 配置纳入版本管理，二是在部署阶段后追加一个自动化冒烟测试步骤，让验证也不再依赖人眼。等到落地后再写一篇续作。