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

Question

我很好奇其他人是如何在严格的变更管理环境中架构他们的DevOps实践的，比如使用变更咨询委员会(CAB)审批过程。

我理解自动化可以通过保证一个更严格、更可证明和更可重复的过程来改进您的审计过程。但是，在这种情况下，持续部署或多或少是不可能的。由于更改可能需要一周或更长时间才能获得批准，因此您将失去快速部署的能力。在这些过程中，除了提交更改请求和等待批准外，您采取了哪些步骤来工作？

Answer 1

如果您必须坚持更改过程，您将受到限制，根据更改过程的限制，完全停止。如果必须在部署之前批准更改，则不能进行持续部署。如果批准需要很长时间，则无法快速部署。没有一种解决办法可以让你既能遵循这个过程，又不会受到它的影响。这就是跟踪变更过程的成本，这是一个值得在这个过程中引起利益相关者注意的成本。

并不是一切都失去了..。您可以最大限度地提高流程的自动化程度，以尽量减少错误；除了生成稳定工件与将工件部署到生产中之间的联系外，所有CD步骤都是如此。该链接将被某种类型的用户干预(按钮、CLI命令等)所取代，或者链接到批准记录(例如，当更改请求票被移动到“已批准”状态时，启动相关部署)。你只需要尽可能多地利用它，同时遵循你所承担的任何强制性过程。当然，这不会让审批变得更快。