如何设计持续集成代码版本发布流程

背景

为了减少沟通成本，提高开发和运维效率，需要提供一套规范的持续迭代发布Apps的流程。而规范的主要目的不在于整体流程本身，在于需要形成一套能够持续迭代优化的发布机制。本文在于提供一套较为完善的代码持续迭代发布的流程方案。

目标

1. 保证完善的发布更新流程，减少回滚的次数。

2. 减少手动操作行为，尽可能自动化完成。

3. 减少发布到客户环境后出现过多问题的次数。

关键环境约束

一般来说，完善的发布流程需要测试环境、预发布环境、生产环境，并且每个环境的权限配置和操作使用者是完全不一样的。

1. 测试环境，大家所有人都是管理员权限，可以操作任何资源，没有限制，所有人员可以进入ssh后台。

2. 预发布环境，仅仅只有测试人员才有操作权限，其他人员只有读的权限，比如查看配置和查看日志，没有任何写权限。只有测试人员才可以进入ssh后台。

3. 生产环境，仅仅只有发布人员有操作权限，其他所有人员只有读的权限，只有发布人员可以进入ssh后台。

预发布环境是开发人员在测试环境测试通过后，测试团队根据开发人员填写的发布文档发布到预发布环境，注意严格按照发布文档来操作，相当于所有操作有记录，避免生产环境发布不成功。

生产环境发布是发布人员在经过测试人员确认发布文档内容可以在生产环境操作后触发。

再次要注意几点：

1. 预发布环境或者生产环境发现BUG，最好能够通过日志系统定位到，如果不行的话需要增加相关日志来定位BUG，实在需要主机ssh权限需要申请并说明理由，并且要思考后续是否可以在代码中解决来避免该问题。

2. 预发布环境一般是测试一周时间，是否测试通过并且可以发布到生产环境是由测试人员来决定。

3. 各种更新升级或者数据库刷数最好能做到自动化完成，减少发布人员的手动操作。

发布流程图

要保证更新和发布自动化完成，首先，需要两部分的资源：

1. 所有APP配置代码化。

只有app安装部署行为代码化后，才可以使用git来进行版本的管理，才能做到可记录，可追溯，可更新，可回滚。（在Kubernetes环境下可以使用Pulumi/Terraform来实现IaC）

1. 所有APP都需要容器化，以镜像对外发布内容。

APP配置分支和APP内容分支之间，仅仅通过镜像来完成两边内容的匹配，并且APP的配置分支命名规则必须和APP内容分支命名规则一致，且发布规则一致。
举例：

项目Hive repo，
分支名称为release#v1.0-20221202，
那么，该分支构建出来的Hive镜像tag为v1.0-20221202。

在pulumi apps repo，
分支名称也要为release#v1.0-20221202,
且hive pulumi app中镜像对应的tag和hive项目构建出来的镜像tag一致，为v1.0-20221202。

备注：项目repo和app repo是独立的两个repo，项目repo主要是项目代码，并完成artifact构建或者docker镜像构建。app repo是该项目对应的应用定义，可能一个项目repo对应多个app。

发布操作流程如下：

1. 开发人员编码，完成镜像构建和测试，并完成app分支镜像版本更新。

2. 每周五，测试人员发布下下周上生产(下周上预发布环境)的上线单，通知有发布功能人员填写。
   发布单内容主要有：app名称，app repo地址，app repo是否创建对应release分支，是否有手动操作，发布失败回归操作方法，预发布环境/生产环境验证是否通过。

3. 每周一，测试人员根据发布单完成预发布环境app更新，并通知相关人员验证，完成验证操作后将验证结果填写到发布单，验证失败则要bugfix，并更新上线单再次上线。

4. 测试人员一周内进行测试和验证。

5. 测试人员验证完毕，可以发布，如果未验证完毕，则需要将推迟发布的app内容填写到下一次发布单上面。

6. 每周一，生产环境发布人员检查本周生产环境上线内容，完成发布，并通知测试人员和相关人员验证。

7. 验证通过，则发布完成，验证失败，则需要提bugfix进行紧急修复，并且要思考该问题为何预发布环境没有发现，后续如何避免。

备注：整体系统功能性验证应该是自动化运行的脚本，预发布环境发布或者生产环境发布后，测试人员会进行统一自动化测试。

备注

1. 重大release分支发布一般会有一个较长的周期，主要区别点在于，重大release分支测试必须要更全面，测试人员，产品人员和相关开发都需要走一遍所有的功能流程。

2. 重大release分支内容一般要开发/产品/测试提前沟通确定好，确定好内容后，该分支原则上不会做新功能添加，只会做bug修复，相关新功能进入dev分支，走下一次大版本发布。

3. 在确定了release分支可发布后，需要申请空的测试环境，并由产品或者其他测试人员走几遍整体从0开始安装发布流程和验证流程，相关测试验证做了2-3次后，可以封版。

版本命名规则

在开源世界，实际上有一个通用的代码版本标准，称作 SemVer 规范。具体参考如：https://semver.org/