Saturday, October 12, 2013

The Deployment Manifesto

This has nothing to do with the word devops. Instead, this is a discussion about certain responsibilities in which both the ops teams and the developer teams overlap. This is about cooperation between teams to create a better product.

The 10 Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     "OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

1. Configuration management MUST NOT be coupled to an external service, such as EC2, Openstack, Foreman, or anything else.

2. Devops SHOULD provide a self-service framework for the automatic creation and destruction of hosts from the ground up.

3. Devops SHOULD work with engineering teams to come up with continuous deployment strategy that doesn’t involve the destruction and creation of fresh operating systems.

4. All code required for deployments MUST be maintained in a centralized source repository. 

5. Deployments MUST use immutable snapshots -- such as a git tag -- from source code.

6. Hosts being provisioned MUST get their configurations from source control and MUST NOT rely on resources from an individual user or an engineer’s local computer.

7. Developers MUST provide a way to test code before it is deployed.

8. Devops MUST have an automated and tested rollback plan with every deployment.

9. Devops SHOULD provide feedback and planning support for hardware, infrastructure, and software dependencies necessary to run applications.

10. Devops MUST monitor all deployments and have clear, identified benchmarks for success or failure.


  1. #3 is interesting to me; if you could drive your OS deployment time suitably low - on the order of single-digit seconds instead of minutes - would you say it still applies? If so, why? Thanks.

  2. Nelson, that depends. If I had that kind of efficiency I would use it provided I could duplicate that type of deployment across multiple sites / datacenters / cloud providers.