华为云CodeArts实战：管、代码托管流水线构建部与

一、背景：为什么用CodeArts把开发和发布串起来

很多团队的交付还停在“代码在各自电脑里、发布靠手工上传”这一步：需求在表格里，开发状态对不上；分支命名随手起，上线时不知道包含哪些改动；构建在某个人的机器上才能过，换一台就缺依赖；测试通过与否靠口头同步，出了问题很难回退到某一个确定的版本。自己用分散的工具也能拼出一套流程，但权限、通知和产物传递都要靠人盯。

华为云 CodeArts 把需求、代码仓、流水线、构建、部署和测试放进同一套控制台：先把事项拆成可跟踪的需求，再在代码仓里按分支提交和评审，然后用流水线把构建、测试和部署按固定顺序跑完。它和在自己机器上执行构建命令不是一回事——后者环境很难复制，CodeArts 把“同一次提交对应同一次构建产物、再部署到指定环境”收成可重复的任务。本文按“认清模块 → 需求管理 → 代码托管 → 流水线构建部署 → 接入测试”的顺序实操一遍。菜单名称以控制台当前版本为准。

二、核心概念

项目：一次协作的工作空间，需求、代码仓、流水线、测试计划和成员权限都挂在项目下。项目名称建议带产品和环境范围，例如 proj-order-svc。

需求：可跟踪的事项，可以是故事、缺陷或任务。需求编号记为 <需求编号>，负责人、优先级和验收标准要写清楚，避免只写一句标题。

代码仓：托管源代码和提交历史的仓库。仓库地址记为 <仓库地址>，默认分支记为 <默认分支>，功能分支记为 <功能分支>。不要把真实地址写进对外文档。

流水线：按阶段自动执行的路径，通常包括检出代码、构建、测试、发布产物和部署。流水线名称建议带应用和目标环境，例如 pipe-order-test。

构建：根据仓库中的约定生成可部署产物。产物路径记为 <构建产物>，构建号要能追溯到某一次提交。

部署：把 <构建产物> 发布到目标环境。环境记为 <目标环境>，部署账号记为 <部署账号>，凭证不要写进脚本明文。

测试：包括接口、功能和自动化用例。测试计划与需求、构建号关联，失败时要能回到对应的提交，而不是只看到一句“没通过”。

三、需求管理

进入 CodeArts 控制台，先创建或进入项目，再在需求管理里把当前迭代的事项建起来：

1. 按迭代或版本建立计划，只放入本周期真正要做完的事项，不要把所有积压都塞进当前迭代；
2. 拆分需求时写清背景、范围和验收标准。例如“支持按统计日导出汇总”要写清谁来用、导出字段、失败时如何提示；
3. 用 <需求编号> 把需求、分支、提交和流水线运行串起来，提交说明里带上编号，事后才能从线上问题反查；
4. 缺陷单独建项，关联到引入的版本或需求，不要只在聊天里说一声；
5. 状态流转要简单可执行，例如待处理、进行中、待验收、已关闭。状态应由实际进展驱动，不要为了报表手工乱跳。

需求不是写得越长越好，但必须能回答“做完是什么样”。缺验收标准的事项，后面的测试和部署都会各说各话。优先级也要诚实：同一迭代里不能所有事项都是最高优先级，否则排期没有意义。

多人协作时，还要约定谁有权变更范围。迭代中途插入紧急缺陷可以，但要同时移出或推迟同等工作量的事项，而不是只加不减。需求的指派和截止日期应对着团队真实产能，避免全部堆在少数几个人名下。

评审需求时重点看边界：输入为空怎么办、权限不够怎么办、是否影响已有接口。这些内容写进验收标准，测试就可以按同一份标准设计用例，而不必临上线再补。若事项依赖另一个尚未完成的接口，先在需求里标明依赖和风险，不要假设对方会按时提供。迭代结束时做一次回顾：哪些事项跨迭代、原因是估期不准、范围变化还是流水线阻塞，下一次拆分时才能更准。

四、代码托管

在项目中创建或导入代码仓，先把分支策略定下来，再允许日常提交：

1. 保护 <默认分支>，不允许直接推送，必须通过合并请求进入；
2. 功能开发从 <默认分支> 拉出 <功能分支>，分支名带上 <需求编号>，例如 feat-123-export，避免名称无法追溯；
3. 提交信息写清做了什么和为什么，开头带 <需求编号>，不要只写“改一下”或“修复”；
4. 合并前做代码评审，至少一人查看接口兼容性、配置是否写死、密钥是否被提交进来；
5. 仓库里不要存放账号口令、证书私钥和真实环境地址，这些放到部署时的凭证管理中；
6. 大文件和构建产物不要进仓库，仓库只保留源码和必要的构建说明。

检出代码时也用占位符，不写真实地址：

仓库地址 = <仓库地址>
默认分支 = <默认分支>
功能分支 = <功能分支>
检出命令 = git checkout <功能分支>

评审要看的不只是“能不能编译”。更要看这次改动是否把环境地址写死、是否兼容旧数据、是否漏掉回退方式。发现问题时在合并请求里讨论并改完再合，不要先合进 <默认分支> 再补救。如果仓库是多人共用的基础库，还要约定兼容性策略：破坏性变更必须升版本并在需求里说明影响范围。

权限上按角色收口：普通开发者可以创建分支和发起合并请求，维护者负责审核和合并，项目管理员管理成员。离职或转岗时及时收回权限。若必须使用访问令牌，令牌要有过期时间，并只授予当前仓库需要的权限。

发生误提交敏感信息时，不要只在后续提交里删除文件了事，因为历史里还在。应立刻作废相关凭证，再按仓库管理规范处理历史，同时检查流水线日志有没有把密钥打印出来。这比事后在群里提醒一句更加重要。

代码仓还要约定提交频率和合并窗口。长期悬挂的功能分支会很难合回去，尽量让分支只覆盖一个 <需求编号>，做完就评审合并。需要发布热修复时，从当前生产对应的标签拉出修复分支，修好后同时合并回 <默认分支>，避免生产修复在主线上丢失。标签名称带上版本和日期，能够对应到那一次构建产物。

五、用流水线串起构建和部署

代码能合并后，不要再依赖某台电脑手工打包。创建流水线，把从检出到部署的步骤写成固定阶段：

1. 检出：从 <仓库地址> 拉取指定分支或标签；
2. 构建：按项目约定的构建命令生成 <构建产物>，依赖从受控的仓库获取，不要临时从个人目录拷贝；
3. 单元测试或接口测试：测试失败则流水线停止，不进入部署；
4. 归档：把 <构建产物> 和构建日志按构建号保存，保留期要能覆盖一次完整的回退窗口；
5. 部署：把同一份产物发布到 <目标环境>，配置和凭证从环境参数中读取。

关键参数可以写成下面这样的清单，方便不同环境复用同一条流水线定义，只替换占位符：

流水线名称 = pipe-order-test
仓库地址 = <仓库地址>
分支 = <默认分支>
构建命令 = <构建命令>
产物路径 = <构建产物>
测试命令 = <测试命令>
目标环境 = <目标环境>
部署账号 = <部署账号>

使用建议如下：

1. 测试环境和生产环境用同一份构建产物，不要在生产环境再编一次，以免两次构建结果不一致；
2. 环境差异只留在配置和密钥，不留在源码分支上长期分叉；
3. 生产部署建议加人工确认或分批发布，失败时能回到上一个构建号；
4. 流水线权限与人员职责一致，不是每个人都能对生产点发布；
5. 构建机要干净、可重复，禁止依赖“这台机器以前装过什么”。

部署步骤里同样不要出现真实主机地址或账号。需要引用时一律使用 <目标主机>、<部署目录> 和 <服务端口>。部署后做一次健康检查，例如访问应用自己的健康接口或检查进程状态，通过后再切流量；失败则停止后续步骤并保留现场日志。

如果应用有数据库变更，把变更脚本纳入同一条流水线，并明确是先改数据还是先发应用。变更要可回退或可向前兼容，避免应用已经发布、数据结构却只能前进不能后退。这类步骤失败时，流水线应标记为失败，而不是继续把后续服务发上去。

构建时长也要盯。依赖下载反复失败、每次都全量编译、测试没有分层，都会让流水线越来越慢，最后大家又绕回手工发布。可以把依赖缓存放到受控位置，把耗时长的集成测试放到单独阶段，合并请求上先跑快的检查。流水线运行记录要保留提交号、构建号、操作人和结果，审计和回退都靠它。

对生产发布，还可约定时间窗：避开业务高峰，并在发布后的观察期内有人值班看监控和流水线日志。若观察期内错误率上升，按预先写好的步骤回退到上一个构建号，而不是在线上直接改文件。回退演练至少要做过一次，否则真正出问题时才会发现产物保留期不够、或部署账号没有回退权限。

六、把测试接进交付过程

测试不是发布前临时点几下页面。它要能和 <需求编号>、构建号对上。可以按这几层来接：

1. 开发提交前在本地或预检查中跑快速用例，保证明显的回归在进入流水线前就被拦住；
2. 流水线里跑自动化用例，覆盖核心接口和关键路径，失败即失败，不允许“先部署再看”；
3. 测试计划中的手工用例对应验收标准，尤其是权限、对账、导出和回退这些自动化不容易一次写全的场景；
4. 缺陷从测试结果反建需求项，指明构建号、复现步骤和期望结果，修复后用同一批用例回归。

接口测试的请求不要写死真实地址，用环境变量或占位符：

请求地址 = <服务地址>
请求方法 = POST
路径 = <接口路径>
鉴权令牌 = <鉴权令牌>

请求正文示例：

{
  "需求编号": "<需求编号>",
  "统计日": "<统计日>"
}

测试数据与生产数据隔离，不要用真实客户信息做回归。环境被多个流水线共用时，先约定数据编号段或独立空间，避免并行任务互相改数据。测试通过的标准要写进项目约定：不仅是用例全绿，还要包括构建产物已归档、部署健康检查通过。

性能测试和安全检查不必每次合并都全量跑，但应在版本发布前有明确的一次。结果要留下报告和当时的构建号，否则过几周只记得“好像测过”。若自动化用例长期失败又被设为跳过，应视为流程失效，优先修用例或修产品，而不是把失败的阶段关掉了事。

还可以把冒烟测试做成部署后的固定步骤：只覆盖启动、登录和一条主路径，失败则回退。冒烟通过后再做更宽的回归，这样能减少“部署看起来成功、业务其实起不来”的空窗。测试账号按环境发放，权限与真实角色对应，但口令同样走凭证管理，不写进用例库的明文文件。

七、日常协作中容易忽略的事

流程工具不能代替约定。下面这些事不做，流水线即使是绿的，交付仍然容易乱：

1. 所有环境的配置项清单要一致，缺少的项在部署时就应失败，而不是用空值启动；
2. 版本号、构建号和需求列表在发布说明里写清楚，支持人员才能知道这次上了什么；
3. 密钥轮换后要同步更新流水线凭证，并做一次非生产环境的部署验证；
4. 不要用个人账号作为生产部署的唯一身份，人员休假时会无法发布或无法回退；
5. 定期清理无用分支、过期产物和已关闭项目的成员权限，减少误发布面。

把“默认分支是否被保护、生产流水线谁能点、上一版产物能不能回退、失败用例有没有建缺陷”做成每周核对项。新成员加入时，先让他在测试环境走通“建需求、拉分支、过流水线、看测试报告”这一圈，再开放更高权限。

若同一产品有多条流水线，命名和参数要统一，避免测试环境用一套变量名、生产用另一套，复制时漏改。变更流水线定义本身也要评审，因为它和改代码一样能影响生产。比较安全的做法是先在测试项目改流水线，验证后再应用到生产项目。

当构建突然失败，先看是代码改动、依赖变更，还是构建环境变化。把这三类原因分开，处理会快得多。依赖变更尤其要谨慎：随便升级可能让测试环境通过、生产因缓存或权限不同而失败，所以依赖锁定和变更记录同样必要。

八、小结

CodeArts 的关键不是把各个模块分别点开，而是一条能重复的链路：用 <需求编号> 说清要做的事，用受保护的 <默认分支> 和带编号的 <功能分支> 管理改动，用流水线把同一次提交变成 <构建产物> 并部署到 <目标环境>，再用与需求对应的测试决定能不能继续。先把分支策略、流水线阶段、环境和凭证写在一张表上，再日常开发，这样比在个人机器上打包更易交接，也比口头对进度更可靠。

上线后还要关注流水线成功率、构建时长、缺陷重开次数和回退是否可执行。如果新版本出问题，要能迅速部署上一个构建号，而不是在目标机器上手工替换文件。发布前把需求列表、构建号和测试报告放在一起，路径、地址和令牌只放在内部配置里，不要出现在公开博客或代码仓库中。