CI/CD pipelines

"Delivering fast and often is CI/CD. Supporting what you deliver is DevOps."¹

– Burr Sutter

Containers and continuity

One reason that containers (like Docker or Red Hat OpenShift) have been so associated with CI/CD is because they provide rigid and repeatable system environments, which means that there are fewer issues moving between entirely different organizational environments. (That’s the dreaded “it worked on my laptop” defense when a code change moves from development to production.)

With continuous integration, development changes are constantly compiled and built with every check-in, so problems are apparent quicker. This is usually combined with an automated test suite to verify stability or functionality. This continual process of check-in, build, and test maintains a higher quality of code, even at peak demand times.

So what does “continuous” mean to you?

Continuous can mean slightly different things, depending on your development pace and business needs. With a majestic monolith (strong processes and technology with a more traditional application architecture), a release can happen every week with a single, monolithic update, with the only constraint being the requirements for agile sprint processes. With microservices, any service may be updated, with overlapping sprint cycles, so updates to the overall architecture can happen daily.

You can learn more about building a CI/CD pipeline by downloading the “Teaching an elephant to dance” e-book.

Aside from catching and fixing problems quicker, another purpose of CI/CD is to create a safe environment for testing ideas and learning from successes (and failures). Once you have a CI/CD pipeline established, you’re ready to move on to stage 5: Advanced deployment.