<p>In my opinion you are right, Continuous Delivery (CD) is not the control framework of Devops, at least it is not the only possible one.</p>

<p>But in the context of the book you're quoting it gets the most used possibility when you start to include security baseline and assessments as part of the product delivered. </p>

<p>In a security context, you'll add smoke tests in a post deploy phase to ensure your application is not subject to XSS or Sql injection for example. If any of this tests fail, block any deploy in other environment, mark the deploy as failed and eventually rollback to previous version.<br>
This enforce the security rules to be satisfied, and in this way act as a control framework to ensure production deploy are 'safe' for known vulnerabilities.</p>

CC BY-SA 3.0
2017-03-28T08:06:18.267Z
2017-03-28T08:06:18.267Z
Tensibai
<p>I would say 'Yes' in the context of 'Security as Code', e.g.:</p>

<p>As the author stated, if I have continuous delivery that means I have continuous integration, which implies I can easily integrate and propagate change throughout the system, and likely this is due to prescriptive code-based configuration.</p>

<p>This alone could be a form of control as you can hopefully easily propagate compliance related changes across your infrastructure</p>

<p>However, I think configuration management exemplifies compliance controls in a devops lifecycle. Look at Chef\DSC and InSpec\ServerSpec. You can run configuration management during the bake phase to set initial configuration and then run it on a schedule after deployment as a form of compliance to eliminate drift. InSpec\ServerSpec tools sit outside that CM and 'audit' the state of the systems to ensure the CM is doing its job.</p>

CC BY-SA 3.0
2017-04-02T07:42:25.320Z
2017-04-02T07:42:25.320Z
Ethan Edwards
<p>I've been reading <a href="http://www.oreilly.com/webops-perf/free/devopssec.csp?download=true" rel="nofollow noreferrer">Jim Bird's DevOpsSec</a> book, one of the statements in <a href="https://www.safaribooksonline.com/library/view/devopssec/9781491971413/ch04.html" rel="nofollow noreferrer">Chapter 4 - Security as Code</a> is as follows:</p>

<blockquote>
  <p>Agile ideas and principles—working software over documentation, frequent delivery, face-to-face collaboration, and a focus on technical excellence and automation—form the foundation of DevOps. <strong>And Continuous Delivery, which is the control framework for DevOps</strong>, is also built on top of a fundamental Agile development practice: Continuous Integration. <em>(O'Reilly 2016, ISBN 9781491971413)</em></p>
</blockquote>

<p>My understanding of a <a href="https://en.wikipedia.org/wiki/Internal_control" rel="nofollow noreferrer">control framework</a> was that it declares certain Control Objectives such as:</p>

<ul>
<li>Payments are made only for authorised products and services received.</li>
</ul>

<p>This may be satisfied by some process built into the system, and would likely have a number of checks and balances; however, you wouldn't say that that process <em>is</em> the Control Framework.</p>

<p>To me it feels that that sentence should read: "And Continuous Delivery <em>satisfies</em> the Control Framework for DevOps".</p>

<p>Am I totally wrong? Is Continuous Delivery the Control Framework for DevOps?</p>

<p>Or, am I right and Continuous Delivery is not the control Framework for DevOps?</p>

CC BY-SA 3.0
2017-03-27T20:56:56.443Z
Aww , how you twist it to come to a question is fun. +1 for the voluntary ´naive ´ interpretation. Have to think how to tackle it now :/
Tensibai
CC BY-SA 3.0
2017-03-27T21:00:50.783Z
Ha - part of me wants someone to say, no, you have missed the point of Control Frameworks and this is the reality.  My life would be so much simpler that way.
Richard Slater
CC BY-SA 3.0
2017-03-28T04:55:25.683Z
Sorry if I have been rude, that was not the intent. I'll try to write my interpretation of it
Tensibai
CC BY-SA 3.0
2017-03-28T05:21:03.413Z
The answer is easy: No.  Continuous Delivery is one of the many frameworks used during an implementation of DevOps ideas, in one very specific area. Kanban is another type of DevOps framework. It is not "the" framework, it is just one of many. Even when it comes to Software Delivery specifically, CD is just one way to do it. I know, I've implemented successful alternative long before DevOps was even a thing.
Jiri Klouda
CC BY-SA 3.0
2017-03-28T07:08:10.690Z
@Tensibai not rude at all, looking forward to your answer.
Richard Slater
<terminology><control-framework>
Is Continuous Delivery the Control Framework for DevOps?
Richard Slater
# Is Continuous Delivery the Control Framework for DevOps?

(Asked by: username_0 on 2017-03-27)

I've been reading [Jim Bird's DevOpsSec](http://www.oreilly.com/webops-perf/free/devopssec.csp?download=true) book, one of the statements in [Chapter 4 - Security as Code](https://www.safaribooksonline.com/library/view/devopssec/9781491971413/ch04.html) is as follows:

> Agile ideas and principles—working software over documentation, frequent delivery, face-to-face collaboration, and a focus on technical excellence and automation—form the foundation of DevOps. **And Continuous Delivery, which is the control framework for DevOps**, is also built on top of a fundamental Agile development practice: Continuous Integration. *(O'Reilly 2016, ISBN 9781491971413)*

My understanding of a [control framework](https://en.wikipedia.org/wiki/Internal_control) was that it declares certain Control Objectives such as:

* Payments are made only for authorised products and services received.

This may be satisfied by some process built into the system, and would likely have a number of checks and balances; however, you wouldn't say that that process *is* the Control Framework.

To me it feels that that sentence should read: "And Continuous Delivery *satisfies* the Control Framework for DevOps".

Am I totally wrong? Is Continuous Delivery the Control Framework for DevOps?

Or, am I right and Continuous Delivery is not the control Framework for DevOps?

**Tags:** terminology, control-framework

> **Comments:**
> **username_1**: Aww , how you twist it to come to a question is fun. +1 for the voluntary ´naive ´ interpretation. Have to think how to tackle it now :/  
> **username_0**: Ha - part of me wants someone to say, no, you have missed the point of Control Frameworks and this is the reality.  My life would be so much simpler that way.  
> **username_1**: Sorry if I have been rude, that was not the intent. I'll try to write my interpretation of it  
> **username_2**: The answer is easy: No.  Continuous Delivery is one of the many frameworks used during an implementation of DevOps ideas, in one very specific area. Kanban is another type of DevOps framework. It is not "the" framework, it is just one of many. Even when it comes to Software Delivery specifically, CD is just one way to do it. I know, I've implemented successful alternative long before DevOps was even a thing.  
> **username_0**: @username_1 not rude at all, looking forward to your answer.  

---

## 2 answers

### Answer by username_1 on 2017-03-28. Score: 3 | Accepted answer

In my opinion you are right, Continuous Delivery (CD) is not the control framework of Devops, at least it is not the only possible one.

But in the context of the book you're quoting it gets the most used possibility when you start to include security baseline and assessments as part of the product delivered.

In a security context, you'll add smoke tests in a post deploy phase to ensure your application is not subject to XSS or Sql injection for example. If any of this tests fail, block any deploy in other environment, mark the deploy as failed and eventually rollback to previous version.  
This enforce the security rules to be satisfied, and in this way act as a control framework to ensure production deploy are 'safe' for known vulnerabilities.


---

### Answer by username_3 on 2017-04-02. Score: 2

I would say 'Yes' in the context of 'Security as Code', e.g.:

As the author stated, if I have continuous delivery that means I have continuous integration, which implies I can easily integrate and propagate change throughout the system, and likely this is due to prescriptive code-based configuration.

This alone could be a form of control as you can hopefully easily propagate compliance related changes across your infrastructure

However, I think configuration management exemplifies compliance controls in a devops lifecycle. Look at Chef\DSC and InSpec\ServerSpec. You can run configuration management during the bake phase to set initial configuration and then run it on a schedule after deployment as a form of compliance to eliminate drift. InSpec\ServerSpec tools sit outside that CM and 'audit' the state of the systems to ensure the CM is doing its job.


---

