连续交付是DevOps的控制框架吗？
我一直在阅读吉姆·伯德的DevOpsSec的书，第4章-安全即守则中的一个陈述如下：
敏捷的思想和原则--在文档之上工作的软件，频繁的交付，面对面的协作，以及对技术卓越和自动化的关注--构成了DevOps的基础。连续交付是DevOps的控制框架，它也建立在一个基本的敏捷开发实践之上:持续集成。(2016年O‘’Reilly，ISBN 9781491971413)
我对控制框架的理解是，它声明了某些控制目标，例如：
- 只为已获授权的产品及服务付款。
这可能是由系统中内置的某些进程来满足的，并且可能有很多的制衡；但是，您不会说该过程是。
在我看来，这句话应该是：“并且连续交付满足DevOps的控制框架”。
我完全错了吗？连续交付是DevOps的控制框架吗？
或者，我是对的，连续交付不是DevOps的控制框架吗？
回答 2
DevOps用户
发布于 2017-03-28 08:06:18
在我看来，您是对的，连续交付(CD)不是Devops的控制框架，至少它不是唯一可能的框架。
但在本书的上下文中，当您开始将安全性基线和评估作为交付的产品的一部分时，您就会引用其中最常用的可能性。
在安全上下文中，您将在部署后阶段添加冒烟测试，以确保应用程序不受XSS或Sql注入的限制。如果其中任何测试失败，则阻止其他环境中的任何部署，将部署标记为失败，并最终回滚到以前的版本。
这将强制执行要满足的安全规则，并以此作为控制框架，确保生产部署对于已知的漏洞是“安全的”。
DevOps用户
发布于 2017-04-02 07:42:25
在“安全即守则”的范围内，我会说“是”，例如：
正如作者所说的，如果我有连续的交付，就意味着我有持续的集成，这意味着我可以很容易地在整个系统中集成和传播更改，这很可能是由于基于规范代码的配置。
这本身就可能是一种控制形式，因为您希望可以轻松地在基础结构中传播与遵从性相关的更改。
然而，我认为配置管理是开发生命周期中遵从性控制的典范。看看厨师\DSC和InSpec\ServerSpec。您可以在烘焙阶段运行配置管理，以设置初始配置，然后在部署后按计划运行配置，以消除漂移。InSpec\ServerSpec工具位于CM之外，并对系统状态进行“审核”，以确保CM完成其工作。
https://devops.stackexchange.com/questions/693
复制相似问题
腾讯云开发者
