CI/CD: Software That’s Always Ready for Production

Continuous Integration and Continuous Delivery uses automation to ensure that new application code is always tested, secure and ready for deployment so teams can ship to production when the time is right.

Back to Perspectives

Continuous Integration and Continuous Delivery: Your Pipeline to Better Software
A Pivotal Perspective by Michael Coté, Director, Marketing

Your build pipeline is one of your most important software delivery assets. It's the connection between a developer commiting code and adding new functionality to applications in production. Between these two points, the code is built into software, verified with multiple types of tests, checked against audit and security controls, prepared for deployment, and, in some cases, even automatically deployed to production. You'll likely hear the pipeline referred to as "CI/CD," that is, continuous integration and continuous delivery.

This push button deployment is required to keep up a daily application release pace. If you think about it, this amount of pipeline automation is needed for those deploying weekly, and even for teams deploying monthly. By integrating smaller chunks of code more frequently, teams reduce the amount of time it takes to integrate new changes into their product. This also reduces the risk of delaying releases because the build is broken and requires a fix. Thus, having the ability to build and test multiple times a day is key to keeping the release schedule running smoothly. This is the "continuous integration" part of CI/CD.

Once your release is built, tested, and properly logged for compliance and security checks, you need to somehow get it to production. One of the key insights of DevOps is that the tested, certified build is only half of the work. Releasing to production is the other half and just as much the team's responsibility as writing and building the code. You're not done until your code is running in production.

Continuous delivery works hand-in-hand with your modern, cloud platform. The pipeline takes the packaged build through a series of tests on staging and, ideally, production environments. To do this, the pipeline relies on another DevOps principal: treating infrastructure as code. All of the configuration and processes needed to deploy the release to production are managed as if they were application code: checked into version control, tested, and tracked as they should be, as part of the release. Your pipeline takes this production configuration and bundles it with the release. It is then ready to for your platform's automated deployment capabilities to do the final release. This entire process should take minutes. Sometimes the cycle is longer due to complexity or compliance concerns, but it should always take less than a day.

With a fully automated build pipeline, the only human fingers involved are in that first commit. The pipeline does everything else. This amount of automation isn't practical for some organizations’ compliance policies. In such cases, that button gets moved down the pipeline. The release pauses right before deploying to production when a human gets the chance to approve the deploy.

Properly done, a pipeline will automate the vast majority of the work required get a build in production, including compliance and security checks. When you can be ready to deploy to production in minutes, you'll rely on a fully automated cloud platform like Pivotal Cloud Foundry at the end of the pipeline. The two together will have you speeding up your software development lifecycle and quickly improving how your organization functions.

Back to Perspectives