问题描述
公司每2-3周发布一次新的移动应用程序更新。每次发布都会有大约50-60个与之相关的Jira票。每个发布之间的代码更改量非常大。他们没有遵循任何CI/CD流程，所以每个月只会有一两次发布，需要经过CAB的批准。
用户想知道在单个发布中有太多的更改是否是一种糟糕的发布管理方式。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
这个问题的回答并不是非黑即白的，是否是一种糟糕的发布管理方式取决于你的环境和流程的有效性。然而，根据持续交付和持续集成的原则，你所描述的情况与这些原则相悖。
持续交付网站上描述了“分批处理工作”的原则，如下所示：
在传统的软件开发阶段方法中，从开发到测试或测试到IT运营的交接是整个发布的过程：由数十或数百人组成的团队数月的工作。
这听起来就像你的情况。相比之下，持续交付采取了相反的方法，尽可能将每个更改推向版本控制，并尽快获得全面的反馈。分批处理工作有很多好处，它减少了获取反馈所需的时间，使问题的诊断和修复更容易，提高了效率和动力，并防止我们陷入沉没成本谬误。
因此，根据这个比较，你的发布管理方式是“糟糕”的，因为它不是分批处理工作或持续进行的（再次强调，只要一个可行的流程是有效的流程）。
另一本广泛使用的参考书《Google可靠性工程》中有一整章关于发布工程。它说：
我们接受了这样一个理念：频繁的发布会导致版本之间的更改较少。
你的流程似乎与这个说法相悖，虽然你没有指定你使用的测试级别或金丝雀部署，但可以推测出没有持续集成，因此每次新的部署都是高风险的，因为它包含了大量未经测试的更改。
以“SRE逻辑”来看，以这种方式进行操作会增加风险。不合理地期望CAB能够根据对应用程序在目标环境（即生产环境）中的性能或行为的预测和假设做出明智的决策，而不是基于数据。
出于这些原因，以及可能还有其他原因，我认为这个社区的共识是，你的发布管理方式是“糟糕”的。
更好的方式是：
1. 至少进行一定程度的测试，并在每次部署时努力扩展测试范围。
2. 尽可能自动化测试，并在当前无法自动化时提供清晰的测试文档。
3. 进行持续交付，并在测试环境中运行金丝雀部署，努力使该环境与生产环境尽可能接近。
4. 目标是能够部署任何给定的构建，并在出现问题时有回滚的手段，以减少部署所带来的恐惧感。
更小、更频繁的部署意味着每次更改的规模更小，更容易修复，并且持续观察部署过程将更好地了解其可靠性和改进的方向。
自动化、测量、改进。重复。
希望这些信息对你有所帮助！
评论：
1. 我们确实有一个QA团队，但他们标记为通过的票据会在CAB批准之前排队等待。我知道我们的流程很奇怪。当排队中的通过票据部署时，会有很多东西同时进入生产环境。感谢你的回答，提供的链接材料非常有帮助！