从零到一设计一个代码发布系统

最近公司里有小伙伴想开发发布系统，突然想起之前是参与过一整套发布系统的设计的，在这里总结一下吧。

一、工作流

要开发发布系统，首先要知道基本的工作流程。

以上是我理解的一个需求提出到结束会经过的一些步骤，其中涉及PM、RD、UI、QA的一些工作。一个完整的项目生命周期。从需求提出到最终完成，确实需要跨团队的协作。PM通常负责需求的收集和整理，确保项目目标明确；RD进行技术实现和开发；UI设计用户界面，确保可用性和美观；QA进行测试，保证产品质量。

那么，怎么开发一个发布系统，作为这个流程的辅助呢。

二、分支管理模式

在团队协作中，通常有两种常见的分支管理模式，分别适用于不同的开发和发布场景：主干发布+分支开发 和 分支开发+分支发布。

2.1 主干发布 + 分支开发

2.1.1 流程：

1. 主干（main/master）为发布分支：

   • 主干分支始终保持稳定，是唯一的正式发布分支。
   • 只有经过充分测试的代码才会被合并到主干分支。

2. 功能开发在分支上完成：

   • 为每个功能或修复创建单独的功能分支（feature branches）。
   • 开发完成后将功能分支合并到主干。

3. 测试后发布：

   • 主干分支代码经过 QA 测试后，直接用于发布。

2.1.2 优势：

• 主干分支保持稳定，适合小型团队或简单项目，发布流程清晰。
• 开发人员可以专注于功能开发，不干扰发布分支的稳定性。

2.1.3 适用场景：

• 项目规模较小，开发迭代周期较短。
• 对主干分支的稳定性要求高，例如生产环境直接依赖主干分支的代码。

---

2.2 分支开发 + 分支发布

2.2.1 流程：

1. 主干分支用于长期维护：

   • 主干分支仅用作基线或备份，实际开发和发布都在分支上进行，上线完的分支需要合入主干分支。

2. 版本分支发布：

   • 每次发布时从主干或开发分支创建一个新的发布分支（release branches）。
   • 发布分支用于稳定性优化和 Bug 修复，不进行新功能的开发。

3. 开发分支协作：

   • 所有功能开发在开发分支上完成，定期合并到发布分支。

4. 发布分支发布：

   • 发布分支测试完成后用于上线。
   • 如果发布后需要修复紧急 Bug，可直接在发布分支修复并回合主干。

2.2.2 优势：

• 发布分支和开发分支隔离，发布流程更加灵活。
• 适合复杂项目，支持多个版本并行开发和维护。
• 更方便处理紧急修复和长期支持的版本。

2.2.3 适用场景：

• 大型项目，开发周期较长且版本发布频繁。
• 需要维护多个版本的项目，例如同时维护多个生产环境版本。

---

2.3 对比总结

特点	主干发布 + 分支开发	分支开发 + 分支发布
分支稳定性	主干分支始终稳定	发布分支更稳定
适用项目规模	小型项目，简单开发流程	大型项目，复杂开发和多版本维护
紧急修复的处理	主干直接修复	发布分支修复后回合
开发并行性	开发分支和主干可能产生冲突	开发分支和发布分支分离

如何选择：

• 如果团队规模较小且需要快速交付，可以选择 主干发布 + 分支开发。
• 如果团队协作复杂，需要同时维护多个版本，建议选择 分支开发 + 分支发布。

本文涉及的代码发布系统主要是分支开发分支发布的代码管理系统。 理想状态下，流水线的部署应该与发布系统在同个系统中，但是由于发布功能分散在各个系统中，于是导致了在完整的发布流程中我们需要在不同的系统中进行流程的推进。

三、代码发布系统整体流程

了解了以上内容后，我们可以开始开发代码发布系统了。

首先就是建立开发分支的部分，有的团队倾向于在开发完成后再去建立跟prd的关系，有的团队则是在prd完成后直接建立相关的开发分支。如果类似于jira的产品管理工具能够集成在发布系统，那当然是最好的了。

从图中可以看出，该系统需要一定的权限设计，因此在一开始建立分支与需求的关系的时候，就应该先确立测试、开发、开发Leader以进行后续的操作。

测试具备提测打回的权限的，而开发是不具备的。

为了使得该发布系统应用到前端、后端、客户端，部署流程需在后台进行区分和定制化。

四、代码发布系统的详细介绍

4.1 需求开发阶段

这一阶段是软件开发的起始阶段，主要围绕需求分析和代码开发展开。目标是将产品需求文档（PRD）中的功能需求转化为可执行的代码，并通过初步的代码审查与测试，确保代码符合项目的功能与质量要求。

1. 从主干分支获取开发分支

   • 开发人员从主代码库（主干分支）拉取代码，创建一个新的开发分支，并遵循命名规范（如 feature-需求编号）。
   • 在需求与分支关联时，分配相关责任人（开发、测试、开发Leader）。
   • 目的：分支隔离，确保主干稳定，开发新功能不会影响已有功能。

权限角色分配：

角色	权限描述
开发	提测权限
	代码提交权限
测试	提测打回权限
	测试通过权限
	灰度环境打回权限
	上线环境打回权限
Leader	Code Review（CR）通过权限
	灰度环境打回权限
	上线环境打回权限

2. 链接技术需求的PRD

   • 产品需求文档（PRD）是项目的起点，包含了具体的功能、界面、逻辑需求等信息。
   • 开发人员需要充分理解PRD，并转化为技术需求。
   • 在需求评审阶段，明确各项功能需求并确定优先级。

3. 完成需求开发

   • 根据PRD，开发人员进行代码编写，完成功能开发。

   • 此步骤涉及：

     • 代码逻辑实现。
     • 单元测试：验证基本功能。
     • 初步自测，确保没有明显错误。

4. 代码扫描安全检测（可选）

   • 使用代码扫描工具（如 SonarQube）对代码进行安全扫描。

   • 检测目标：

     • 潜在的安全漏洞（如 SQL 注入、XSS 攻击风险）。
     • 代码规范与质量问题（如命名不规范、冗余代码等）。

   • 虚线框表示此步骤可选，可能根据项目的安全要求来决定是否执行。

5. leader 打回

   • 开发完成后，代码提交给团队负责人（leader）进行审查。
   • 如果发现代码质量问题（如逻辑不清、注释不足），代码会被退回，要求修改。

6. Code Review

   • 团队进行代码审查，通常包括：

     • 代码风格与规范的一致性。
     • 功能逻辑的正确性。
     • 性能优化建议。

   • 目标：确保代码符合项目质量标准，为下一步测试做好准备。

7. 测试打回

   • 在提交代码给测试人员进行初步测试时，如果发现功能或逻辑问题，代码会被打回给开发人员重新修复。

4.2 测试环境准入阶段

这一阶段侧重于代码的测试验证，开发人员与测试人员紧密协作，确保功能稳定且无缺陷，为上线做准备。

1. 提交代码

   • 开发人员将修复完成的代码提交至代码仓库，准备部署到测试环境。

2. 上线到测试环境

   • 将代码部署到测试服务器，供测试人员进行功能验证与缺陷测试。
   • 目的：模拟生产环境，提前发现潜在问题。

3. 程序打回

   • 测试人员在测试过程中可能发现问题，程序会被退回开发人员进行修复。

4. 代码扫描安全检测

   • 再次进行代码安全扫描，确保代码修改后没有引入新的安全问题。

5. leader 打回

   • 修改后的代码再次提交给团队负责人进行审查，检查是否符合规范与质量要求。

6. Code Review

   • 经过再次代码审查，确认代码修改符合要求，准备合并到版本分支。

7. 开发分支代码合入版本分支代码

   • 代码通过测试与审查后，合并到版本分支。

   • 目标：为项目发布做版本准备，确保代码一致性与完整性。

4.3 上线阶段

这一阶段是代码的最终验证与部署上线，包含问题修复、集成测试和上线效果评估，同时提供问题回滚与解决机制，确保系统稳定运行。

1. 有BUG，测试打回

   • 在进一步的集成测试中，如果发现BUG，代码会被打回给开发人员修复。
   • 目标：反复测试，确保功能稳定性。

2. 集成测试上线效果评估

   • 代码修复后，进行集成测试，验证整体功能是否正常，确保与其他模块或系统的兼容性。

3. 上线到正式环境

   • 通过所有测试后，代码部署到生产环境，正式向用户提供服务。

端	部署规划
前端	- 实现代码构建和静态资源上传（如部署到 CDN）
后端	- 结合 Docker 和 CI/CD 流程
	- 部署到容器化服务（如 Kubernetes 或云平台）
客户端	- 自动化打包与应用商店上传流程

4. 出现线上问题（可选）

   • 如果上线后发现问题，可以采取以下措施：

     • 本版本解决，回滚：线上环境先回退到上一个稳定版本，版本分支先进行修复，修复完测试通过后再进行上线。
     • 下版本解决： 对于不影响系统运行的问题，可以安排到下一个版本中解决。

5. 代码合入主线

   • 代码最终被合并回主干分支，确保主代码库与最新版本一致。

另外这个过程可以提供一些系统化工具支持：

• 使用版本控制系统（如 Git）和代码托管平台（如 GitLab/GitHub）。
• 集成 CI/CD 工具（如 Jenkins、GitHub Actions）以自动化部署。
• 配置权限管理和日志审计功能，确保流程透明与安全。

以上就是从零到一设计一个代码发布系统的所有过程。