代码冻结:为什么和如何

在2022年8月和9月初，JFrog帮助一家主要的美国电信运营商举办了一系列围绕开发者最佳实践的会议。至少有1300名开发人员参加了一次会议，重点讨论了Docker、Maven、Gradle、NPM、Nuget和PyPi等特定于包的示例。

从这些最佳实践会议中获得的一个有趣的收获是每次会议中出现的关于执行代码冻结的统一问题。

在我们开始之前，这里是代码冻结的含义。

代码冻结意味着代码被冻结，开发人员不会再做任何修改。在代码冻结之后，开发人员不应该更改代码。

冻结代码的目的

每个开发团队都知道代码冻结的含义。虽然他们的原因各不相同，但有两大类:冻结测试和冻结业务连续性。

但是，坦率地说，任何代码冻结从根本上都与CI/CD概念(持续集成、持续开发/部署)不一致。然而，这些冻结的发生是有原因的。

测试冻结发生在一个版本被最终确定并在发布前通过“额外”测试时。常规运行这些测试并不经济，例如手动用户验收测试或描述中带有“手动”字样的任何测试。这些测试不适合支持完全自动化的CI/CD概念。

最常见的以业务为中心的代码冻结是在销售高峰时期，比如黑色星期五或网络星期一。这种代码冻结保留了客户体验——当客户试图购买时，除了最关键的更新之外，您不希望出现任何其他更新。

保护冻结二进制文件

因此，代码冻结是CI/CD生活的一部分。虽然冻结，但开发仍在进行。这导致多个团队提出了一个问题:什么是确保“冻结”二进制文件不会被意外修改的最佳方法?

T一般的建议是将一个准备好进行全部测试的二进制文件提升(移动)到一个RBAC控制比典型更严格的位置。引入可变性和复杂性是为了将覆盖的危险降至最低。

从流程的角度来看，理想情况下，您希望限制此移动。至少要以不同的用户登录。该用户应该只具有向目标存储库写入和从普通存储库读取的权限。这个限制限制了概要文件的普通用户。

每个开发人员最终都会获得他们组的“超级用户”，通常是在他们做一些困难的事情并希望消除所有可能的权限问题时。这个用户的存在通常是好的，但是“冻结”存储库是个例外。超级用户不应该这样做具有写入此唯一存储库的权限。

此外，自动化在这里可能是保存的敌人。使用有限的用户RBAC来移动或提升二进制文件到“冻结”的管道不应该这样做能够被任何其他自动化意外触发。这里有两种基本方法。

第一种方法是不将这个专用管道与任何其他自动化挂钩。在这种情况下，它应该独立作为一个管道，由有限数量的经验丰富的个人手动触发。缺点是这需要手工操作，人员可能会成为瓶颈(重叠的假期或病假可能会使他们无法工作)。

第二种方法是删除用户写入“冻结”存储库的权限。这种方法变得更加可持续，因为任何管理员都可以完成此功能。如果团队可以在任何级别上自助服务，这就变得可行了。Jenkins管道允许团队添加和删除用户和凭证。用户可以是静态的，但是管道凭证可以被删除。

另一种方法是分行政。许多公司已经建立了基础设施来支持自助任务，比如创建和删除用户。有些系统提供直接的子管理，其中RBAC目标可以由开发人员组直接删除(例如JFrog项目方法)。

使用这些方法中的任何一种，目标都是使一个流程能够最好地执行代码冻结，并在理想情况下转向基础设施即代码。因为会发生代码冻结，所以在某种程度上，围绕这个问题的过程很容易涉及到一些操作，因此，这是一个出错的风险区域。

现代DevOps并不是关于完美的自动化，它实际上是关于处理系统中最终失败的每个元素。我们的计划是迅速恢复。我鼓励每个处理代码冻结问题的小组都采取这种心态——考虑一下您现有的流程可能在哪里被打破——然后从那里开始构建您的计划。