敏捷的思想和原则-在文档之上工作软件，频繁交付，面对面的协作以及对技术卓越性和自动化的关注，构成了DevOps的基础。而且，持续交付（这是DevOps的控制框架）也建立在基本的敏捷开发实践之上：持续集成。 （O'Reilly 2016，ISBN 9781491971413）
我对控制框架的理解是它声明了某些控制目标，例如：
付款
只能通过系统中内置的某些过程来满足，并且可能会有很多制衡措施；但是，您不会说该过程就是控制框架。
对我来说，该句子应为：“并且持续交付满足DevOps的控制框架”。
我完全错了吗？
或者，连续交付不是DevOps的控制框架吗？
#1 楼
我认为您是对的，持续交付（CD）并不是Devops的控制框架，至少它不是唯一可行的框架。但是在本书中，您引用的是它当您开始将安全性基准和评估纳入所交付产品的一部分时，您将获得最常用的可能性。
在安全上下文中，您将在部署后阶段添加冒烟测试，以确保您的应用程序不受XSS或Sql注入的限制。如果任何一项测试失败，则阻止在其他环境中进行任何部署，将部署标记为失败并最终回滚到先前版本。
这将使安全规则得到满足，并以此作为控制框架来确保生产部署对于已知漏洞是“安全的”。
#2 楼
我会在“作为代码的安全性”的上下文中说“是”，例如：如作者所述，如果我连续交付，这意味着我具有持续集成，这意味着我可以轻松集成在整个系统中传播更改，这很可能是由于基于说明性的基于代码的配置引起的。
这仅仅是一种控制形式，因为您希望可以轻松地在基础架构中传播与合规性相关的更改
但是，我认为配置管理在devops生命周期中体现了合规性控制。查看Chef \ DSC和InSpec \ ServerSpec。您可以在烘烤阶段运行配置管理以设置初始配置，然后在部署后按计划运行它，这是合规性的一种形式，可以消除漂移。 InSpec \ ServerSpec工具位于该CM之外，并“审核”系统状态以确保CM正常工作。
评论
噢，您如何扭曲它来解决问题很有趣。 +1为自愿的“天真”解释。现在必须思考如何解决它：/哈-我的一部分希望有人说，不，您已经错过了控制框架的要点，这就是现实。这样我的生活会简单得多。
抱歉，如果我不礼貌，那不是意图。我会尽力解释一下
答案很简单：不可以。持续交付是在一个非常特定的领域中实施DevOps创意期间使用的众多框架之一。看板是另一种类型的DevOps框架。它不是“该”框架，只是众多框架之一。甚至就软件交付而言，CD只是实现它的一种方法。我知道，在DevOps还未成为现实之前，我就已经实现了成功的替代方案。
@Tensibai一点都不粗鲁，期待您的回答。