华为云 CodeArts 流水线实战：一次提交自动完成构建、测试与部署

引言

前阵子我负责的一个小项目上线前总要经历一遍“人肉流水线”：本地打包、把产物传到服务器、跑一遍冒烟用例、再手动重启服务。流程走下来常常半小时起步，偶尔还因为某一步漏做导致线上出问题。后来我把整套流程搬到了华为云 CodeArts 流水线上——从那以后，每次向主分支提交代码，构建、测试、部署就自动依次跑起来，整套流程十几分钟自己跑完，中间不需要我盯着。本文记录这次落地的完整过程和踩过的坑。

一、为什么需要一条流水线

手动部署有三个老问题。第一是不可重复：同样的代码，不同的人、不同的时间部署，结果可能不一样；第二是反馈慢：代码合入后要等人工验证才发现问题；第三是风险高：发布步骤依赖个人经验，新人接手很容易漏步骤。流水线的核心价值，就是把“构建—测试—部署”这些重复动作变成可版本化、可复看、可重跑的自动化流程。一次配置好，之后每次提交都能复用。CodeArts 流水线把代码检查、构建、测试、部署串成可视化的阶段，每个阶段由若干任务组成，失败时自动停在当前阶段，日志集中可查，这对小型团队尤其友好。

二、准备工作：三样东西先备好

动手之前，我把三样东西准备好：第一，代码仓。项目代码放在华为云 CodeArts Repo 代码托管里，主分支是 main，开发分支是 dev，流水线默认监听 main 分支的提交。第二，构建配置文件。项目是一个前端页面加一个 Node.js 服务，我在仓库根目录放好 package.json，里面定义了 install、build、test 三个命令，保证本地执行 npm run build 和 npm test 能通过——流水线只是把本地验证过的命令搬到云端执行，本地跑不通的命令云端也不会通过。第三，部署目标。一台华为云弹性云服务器（ECS），事先装好 Node.js 运行时，并创建好部署用的目录和服务启动脚本，部署账号用密钥登录，避免把密码写进流水线。

三、创建流水线：五个阶段一次配好

在 CodeArts 控制台新建流水线，选择“自定义流水线”，代码源选 Repo 里的项目仓库和 main 分支。流水线我拆成五个阶段：

1. 代码检查：用代码检查服务对提交做静态检查，拦截明显的编码规范问题和低级错误。
2. 构建：拉取代码、安装依赖、执行 npm run build，产出可部署的构建包，并归档为制品。
3. 单元测试：执行 npm test，测试报告自动上传，失败则直接阻断流水线，不进入部署。
4. 部署测试环境：把构建产物部署到测试服务器，跑一遍接口冒烟用例。
5. 部署生产环境：人工确认后（设置了审批节点）把同一份制品部署到生产服务器并重启服务。

阶段之间是串行的，前一个阶段成功才进入下一个；同一个阶段里的任务按配置的顺序执行。五个阶段在流水线画布上一目了然，第一次配置大概花了半小时。

四、关键配置详解

1. 代码源与触发方式

触发方式选“代码提交时触发”，分支填 main，这样每次推送都会自动启动一次流水线。为了避免开发分支的频繁提交干扰，我只监听 main 分支；dev 分支的合并请求走单独的代码检查任务，合并进 main 后才触发完整流水线。

2. 构建任务的配置

构建任务用 Node.js 环境，命令写得很直白：先安装依赖，再编译打包，最后把 dist 目录和启动脚本打成压缩包作为制品上传。示例如下：

npm install --registry=https://registry.npmmirror.com
npm run build
tar -czf app.tar.gz dist package.json start.sh

依赖安装的源地址、Node.js 版本都固化在配置里，避免因环境差异导致“在我机器上能跑”的问题。

3. 测试任务与质量门禁

测试任务执行 npm test 并收集覆盖率。我给流水线加了一条质量门禁：单元测试通过率必须为 100%，且新增代码的行覆盖率不低于 70%，否则流水线失败。这样做的好处是质量底线被写进了流程里，不再依赖个人自觉。

4. 部署任务的配置

部署使用 CodeArts 部署服务的主机组方式：先把 ECS 纳入主机组，部署任务通过 SSH 把制品传到服务器的发布目录，解压后执行启动脚本：

cd /opt/myapp
tar -xzf app.tar.gz
bash start.sh restart

部署到生产环境的阶段前加了一个人工审批节点：流水线跑到这里会暂停并通知我，确认无误后点“继续”才执行，相当于给生产发布加了一道人工保险。

五、一次完整提交的端到端过程

上面这套配置跑起来之后，一次典型的提交是这样走的：我在本地改完代码，先跑一遍 npm run build 和 npm test，确认通过后把提交推送到 main 分支。推送后几秒钟流水线自动启动：先做代码检查，大约半分钟；接着构建阶段拉取代码、安装依赖并打包，大约三分钟；单元测试一分多钟通过；随后部署到测试环境并自动跑接口冒烟用例，约两分钟；我收到审批通知，在手机上确认后，生产部署一分钟左右完成，全程大约八到十分钟。整个过程不需要守在电脑前，流水线的每个阶段都有明确的成功或失败状态，失败时会在对应任务的日志里看到具体报错，点击“重新执行”即可从失败的阶段继续跑，不用从头再来。

六、踩坑记录：五条最值得注意的经验

1. 依赖安装超时：第一次跑构建时 npm install 花了很久还超时，原因是默认源在国外网络不稳定，改成国内镜像源后安装时间从十几分钟降到两分钟内。
2. 构建产物路径写错：打包命令里写的是 dist，实际构建输出目录却是 build，流水线打包了个空目录，部署后服务起不来。教训是先在本地核对一次产物路径再写进配置。
3. 测试用例依赖本地服务：有个用例依赖本机起的数据库，云端没有这个服务，测试一直失败。改成用内存数据库做测试依赖后，测试在任何环境都能跑。
4. 生产部署没有审批：最初我图省事没加审批，有一次测试环境的冒烟用例漏了一个场景，代码直接上了生产。加上人工审批节点后，生产发布多了一道确认，风险明显降低。
5. 密钥与敏感信息：早期我把服务器密码写进了部署脚本里，后来改成用 CodeArts 的凭据管理存放密钥，流水线只引用凭据名称，不再出现明文密码。

七、进阶：通知、回滚和多分支策略

流程跑顺之后，我又加了三处改进。第一是通知：流水线执行结果接入企业微信机器人，成功或失败都会推送一条消息，失败时附带日志链接，定位快很多。第二是回滚：每次部署前把上一版本的制品备份一份，生产出现问题时，直接用备份的制品重新执行部署阶段，几分钟就能回滚到上一版。第三是多分支策略：main 分支负责生产发布，release 分支负责预发布环境，dev 分支只做代码检查和构建，分支和环境的对应关系写死在流水线配置里，新人接手一看就懂。

八、总结

把“一次提交自动完成构建、测试与部署”落地之后，团队的变化很直观：部署从半小时人工操作变成十分钟自动执行，发布失败率明显下降，出了问题也能从流水线日志快速定位到具体哪一步。回头看整个实践，最关键的三点是：第一，流水线配置本身要像代码一样认真对待，写进仓库、做版本管理、做评审；第二，质量门禁和人工审批要搭配使用，自动化负责效率，人工负责关键决策；第三，先把本地构建和测试跑通，再搬到流水线上，云端环境只是执行器，不替你修本地就存在的问题。如果你也在用华为云做开发，不妨从一条最简单的“提交—构建—部署”流水线开始，先跑通，再逐步加上测试、代码检查和审批，一步步把自己的发布流程自动化起来。