First let’s talk about the acronyms CI, CD and CD… This whole CI / CD thing causes all sorts of confusion. First CI is Continuous Integration, for a definition see my previous post here: What is Continuous Integration. CD, now that’s a little trickier… CD is either Continuous Delivery or Continuous Deployment depending on where you are in the pipeline. So then what is Continuous Delivery really? The textbook definition of continuous delivery is as follows:
Be ready and able to deploy any version of the solution to any supported platform at any time.
But what does that mean Exactly? Before we break down the definition of Continuous Delivery lets list a few key enablers.
- Test Driven Development
- Developing on Trunk
- Implementing Feature Flags
- Automated Acceptance Testing
- Configuration Management
- Automated Deployment
As we break down the definition of Continuous Delivery we will see where each of these processes helps to enable Continuous Delivery.
First let’s talk about being ready and able. If your boss or a client were to come to your team’s work area right now and say “hey, you geeks deploy that solution right now!” how long would it take you to get it into production? Will it take 15 minutes, an hour, 8 hours, 48 hours or more? If we want to be “ready and able” to deploy at any time we can’t have a bunch of incomplete features, untested code, branches that need to be merged and bugs that need to be fixed. Since there will always be times that a feature is not complete because the developer is still working on it we can use Feature Flags. Feature Flags disable, hide or restrict access to code when committing changes to source control so that the solution can deployed at any time. For example, imagine you are adding a new login functionality to your solution. The developer has created the login page but the login database has not yet been created therefore the login page will not work. We can use Feature Flags to commit the new login page to source control while keeping the login feature disabled. Using Feature Flags also to develop changes without branching because the primary reason for branching is to avoid changes breaking the codebase and restricting our ability to deploy. We call this approach Developing on Trunk (get it no branches it’s just the trunk) To make sure that we can deploy quickly after changes are committed to source control we need to make sure that the code is already well tested automatically as its committed. We call this technique Continuous Integration but in order to have the tests available at commit we must also implement Test Driven Development also known as Test First Development. To ensure that we can repeat the deployment process on demand and in a reasonable amount of time Configuration Management must be automated as well to a point that we can reconfigure servers as settings files stored in Source / Version Control. Configuration Management avoids issues like Configuration Drift, Snowflake Servers and Inconsistent Environments. Configuration Management also allows us to maintain installation and configuration settings in Source / Version control for all previous versions enabling deployment of “any supported version to any platform”. Lastly while we just need to be “ready and able” to deploy we still need to ensure that deployment is not a painful or high-risk process. Deployment needs to be a push button, single click, low risk event. To accomplish this deployment must be automated. Automated Deployment can be achieved in many different ways from batch files and scripts to release management software. The way you automate is as import as the fact that you actually do Automate Deployment.
As you begin your journey of Continuous Improvement to your Solution Delivery Pipeline remember this “You do not need to solve all the world problems in the first iteration”. Make incremental improvements to your current process, collect feedback and integrate that feedback into the next iteration to Continuously Improve the Solution and the Process.