我很好奇其他人如何在严格的变更管理环境（例如，变更顾问委员会（CAB）批准流程）中构建其DevOps实践。更严格，可证明和可重复的过程。但是，在这种情况下，感觉连续部署几乎是不可能的。由于可能需要一周或更长时间才能批准更改，因此您将失去快速且经常部署的能力。除了提交变更请求和等待批准之外，您还需要采取哪些步骤来进行这些工作？
#1 楼
如果您必须坚持变更流程，那么根据变更流程的局限性，您将受到限制。如果必须在部署之前批准更改，则无法进行连续部署。如果批准需要很长时间，则无法快速部署。没有解决方法可以使您既可以遵循该过程又不受其影响。这就是遵循变更流程的成本，并且值得在该流程中引起利益相关者的关注。为了减少错误；除了生成稳定工件和将工件部署到生产之间的链接之外，所有CD步骤均如此。该链接将由某种类型的用户干预（按钮，CLI命令等）替换，或链接至批准记录（例如，将变更请求票证移至“已批准”状态时，触发关联的部署）。您只需要从中获取最大的收益，同时遵循您所苦恼的任何强制性过程即可。当然，它不会使批准速度更快。
评论
是的，这也是我的评估。我更好奇使用CAB流程的其他人如何处理事情。
–埃里克·冯肯布施（Erik Funkenbusch）
17年5月6日，0：14
通常通过哭泣成含酒精的饮料。这是管理控制与敏捷开发的永恒冲突。
–阿德里安
17年5月6日，0：15