严格的变更管理政策协调持续部署

我很好奇其他人如何在严格的变更管理环境（例如，变更咨询委员会（CAB）批准流程）中构建其DevOps做法。

我知道自动化可以通过保证更严格，可证明和可重复的过程来改善您的审核过程。但是，在这种情况下，感觉连续部署几乎是不可能的。由于可能需要一周或更长时间才能批准更改，因此您将失去快速且经常部署的能力。除了提交变更请求和等待批准之外，您还需要采取什么步骤来在这些流程中工作？

如果您必须坚持变更流程，那么根据变更流程的限制，您将受到限制。如果必须在部署之前批准更改，则无法进行连续部署。如果批准需要很长时间，则无法快速部署。没有任何解决方法可以使您既可以遵循流程又可以不受其影响。这就是遵循变更流程的成本，并且值得在该流程中引起利益相关者的关注。

没有失去一切......你可以最大限度的自动化周围的过程中，为了最大限度地减少错误; CD的所有其他步骤，除了生成稳定工件和将该工件部署到生产之间的链接之外。该链接将由某种类型的用户干预（按钮，CLI命令等）替换，或链接至批准记录（例如，将变更请求票证移至“已批准”状态时，触发关联的部署）。您只需要从中获得最大的收益，同时遵循您所苦恼的任何强制性过程即可。当然，它不会使批准速度更快。