Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

In effectively using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility

Motivations (Similar to Non-Cloud CD)

• Reduce Cycle Time and Accelerate Feedback
• Fix problems faster; Troubleshoot more quickly
• Get features to users quicker
• Reduce repetitive error-prone manual processes

Principles

• Abundance over Scarcity
• Reduce and Eliminate Assumptions
• Continually Validate the Source of Truth
• Reduce Infrastructure Costs

High-Level Practices

• Dispose Early and Often
• Recreate from Source
• Use Binaries to Speed Environment and Deployment Creation

Patterns

• Ephemeral Environments: Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
• Software Systems as Code: All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
  • Infrastructure gets "built" just like the application code
• Self-Service Deployments: Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
• Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
• Disposable Environments: Non-Production Environments are automatically terminated based on team policies. Open-source tools like CloudPatrol and Janitor Monkey can assist with this.
• Responsible team members will only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

Antipatterns

• Fixed Environments (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
• Stale Environments Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
• Fragmented Automation - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
• Partial Deployments - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
• Shared Environments - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
• Locking down Environments - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.