DevOps - Continuous Deployment patterns

The goal of this short article is to list some patterns of devOps Continuous Deployment, and the way to implement (at a glance, not technically) a CD pipeline.

In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand. — Erik to Grasshopper, The Phoenix Project

We take for granted that your Environment has the following assets implemented and understood / mastered :

• Mindset : agilemanifesto.org
• Method : SCRUM, KANBAN, SAFe, Scrumban, XP...
• Agile software engineering : softwarecraftsmanship.org
• Continuous Integration plateform (including automated tests and feedbacks)
• Code repository (softwares, scripts, configurations...whatever is - or can be - coded)
• Artefacts repository (artifactory, Nexus...)
• Homogeneous environments
• Production (efficient) monitoring
• Infra As Code (if possible regarding your project)
• Microservices, Api... whatever is not a big monolithic piece of software
• Cloud - IaaS, PaaS (if possible regarding your project, not mandatory but really a big enabler)
• A good reason to deploy continuously (maybe I can put that item first on the list)

If you don't have all of the above list's items checked, think about CD later, maybe you have some other steps to climb before doing CD.

Now that you master your Dev processes and have an Agile infrastructure, you can begin to implement CD. Here are some patterns to foster Continuous Deployment (please note that deploying in production doesn't mean to "release" the features for the users) :

• Version control – Everything has to be versioned, from code to deployment scripts, artefacts, environments... The goal is to be able to manage the traceability and do a fast roll-back if needed (but remember that only real men don't roll-back).
• Feature toggles – a technique to facilitate dark launches (the ability to deploy to a production environment without releasing the functionality to end users) by implementing toggles in the code, which enables switching between old and new functionality.
• Self-service deployment – when automation deployment is not fully implemented, self-service deployment allows a single command to take solutions from staging to production.
• Deployment automation – All the actions to deploy a tested solution automatically from check-in to target environments (automated self-service deployment).
• Selective deployment – the ability to deploy to specific production environments and not others based on criteria such as geography, user role, etc. - Facebook implemented that pattern and "canary test" the new version in production (deployment in a narrow area).
• Blue/green deployment – a technique that permits automatic switching between two environments, one for deployment and one that is live. This technique is one of the "zero downtime deployment" patterns.

As you can see, there is several patterns to implement Continuous Deployment. Now you have to wonder why you want to do continuous deployment, what you want to improve (Time to market, lower risks, quick feedback...), and which path you have / want to take.

Don't forget that CD is not a goal, it's just a tool to help you improving something.

Share your experience of CD implementation

Inspiration and some infos from SAFe body of knowledge