Strategies for Implementing Continuous Integration/Continuous Deployment

Source:- cmswire.com

Continuous Integration/Continuous Deployment, or CI/CD, is the process of building automation into the software release process. It is becoming more necessary as companies move to microservices architectures, which involve many moving parts. Any type or part of software can benefit from CI/CD because it makes software releases faster and less error prone.

Implementing CI/CD is not an easy task. Initially, pipeline processes need to be designed, although basic templates that can be followed. Then, toolchain decisions need to be made, especially deciding if an end-to-end or self-integrated DIY CI/CD solution will be deployed. These processes will be unique to each environment and toolchain choices are based on resources and needs as much as features.

Any automation is scary when it touches production systems. What if something is designed wrong? Will the initial implementation slow rather than quicken critical software releases? Are these the right tools and will they grow with the organization?

In researching CI/CD for an upcoming set of papers, I found a number of compelling implementation strategies. They all emphasize one thing: Go slow, then grow. Here are four strategies that will work for companies of all sizes.

Related Article: CI/CD Is DIY So Metrics Can Be OMG

Be Selective About the Code You Automate

It’s easy to decide to automate all types of code, all at once. That increases risk dramatically, since it takes time to refine pipelines for different types of artifacts. Instead, DevOps teams have succeeded by taking a selective code strategy, which basically means starting with one type of code, say infrastructure as code YAML, SQL or configuration files. By starting with a class of code, risk is spread across applications and only to a small part of an application.

Take an Incremental Approach to Process Deployment

Another strategy is to implement only one part of the total process at a time. For example, automating merges or builds. This allows the team to get one part of the process right and error free before going on to the rest of the process. Think of it as not biting off more than you can chew.

Related Article: Version Control Systems: The Link Between Development and Deployment

Start With 1 Application at a Time

Rather than trying to implement CI/CD for all applications, start with one application, perhaps one that is not mission critical. When that is working totally right, move on to more challenging CI/CD pipelines. Risk is therefore concentrated into lower value systems until IT is confident they can do this for more applications.

Limit the Damage to IT

Finally, start with applications that affect IT more than anyone else. This limits the impact of early deployment snafus to IT and not the rest of the business. Even if something goes deadly wrong, the inconvenience is only felt by IT, who can better manage the fallout.

Truthfully, some combination of all of these makes for the best strategy. Starting with part of a single, IT-oriented application limits the blast area considerably and allows for significant improvements to occur before the business or, especially, customers may be affected.

The go slow then grow concept allows DevOps teams to get the bugs out while keeping end-user confidence high. That doesn’t mean growth needs to be slow forever. Once the processes, toolchains and integrations are working, rollouts to more applications that have high need, such as microservices applications on Kubernetes platforms, can happen much more quickly. CI/CD rollouts can then accelerate until they reach all the systems they are meant to serve.

About the Author

Tom Petrocelli is a contributing analyst with Amalgam Insights. His area of interest is collaboration and new ways of work, developer tools, IT project efficiency, governance, and methodologies, and DevOps.AddThis Sharing Buttons