We wanted to do a post today on two of the most advantageous aspects of cloud native architecture: continuous integration and continuous deployment, or CI/CD for short.
While these concepts technically are not new with tooling such as Jenkins long preceding the explosion of cloud services, they've taken on new meaning and implementation standards as part of cloud native architectures.
The terms continuous integration and continuous deployment are often used interchangeably, so defining the differences between them is necessary.
What Is CI/CD?
In short, continuous integration is the practice of committing updates to software code, running builds, and testing - all in an automated fashion with no human intervention.
As an extension to continuous integration, continuous deployment is the automated release of those updates into production after the automated builds and testing have been completed.
So a way to look at CI/CD as joint concepts would be that continuous deployment is a way of releasing software to users in an automated way that comes after continuous integration has be completed.
Below is diagram of how this process works.
The Old Paradigm
The benefits of continuous integration and continuous deployment to an organization are massive, especially when it comes to speed to market.
Traditionally, software companies would release software, work on new changes, and then set a release date in which all old versions of software would be replaced with the new version, whether as update installer or web application rollout.
This not only proved very stressful for software development teams because everything needed to go right on release day, but it also had potential to cause systematic issues across a customer base because if something was wrong with the new software, the problem is now in front of every single customer.
To make a poker analogy, release day was the day that software companies would need to push all their chips in that the new version of the software was both ready to go and backwards compatible with customers' data.
In other words, software companies had to bet the farm every time they released new features that everything would work as expected. If they were wrong, they could lose vital customers.
Talk about stress!
The New Paradigm
Somewhere along the lines, some smart people decided "you know what, this process of releasing new software is actually pretty risky!" Not only that, its slow and not very efficient because every time we release new features or fix something, we have to call all these meetings to get everybody on the same page internally. There's gotta be a better way!"
Enter CI/CD. Continuous Integration and Continuous Deployment were ways for software development teams to not only automate the mundane processes of running and documenting build/test results manually, but also deploying finished products into production in a more agile and less risky way.
For example, one of the main features of some CI/CD pipelines is that a portion of customer traffic can be diverted to the new version of web software, while the rest of a company's customers are still on the old version. This allows a company to monitor how the new updates behave with real customer traffic, but with a much smaller subset.
This practice is call blue/green deployments and it reduces the risk of new releases substantially because if something goes wrong with the new version, you can just roll back changes and divert the customers back to the old version.
CI/CD With Containers
The emergence of CI/CD practices coincides with another rapidly emerging technology that is helping software teams become more agile in deploying software: containerization.
Without diverting too much from our main topic, containers provide software teams a way to "build once, run anywhere" with their code bases so that their software runs as expected in various environments.
Containers provide a smaller footprint and allows software builds to be much more lightweight and portable in terms of size, which means better performance and delivery.
Naturally, containers lend themselves to being built and deployed with continuous delivery pipelines as part of a cloud native ecosystem. And with container orchestration frameworks like Kubernetes on Google Cloud, the practice of CI/CD for containers is rapidly evolving.
In our next post, we'll discuss containerization more in depth, and show how its changing the CI/CD game to allow software development teams to develop and release even faster with better availability.
KaizenTek provides CI/CD expertise within a variety of CI/CD frameworks such as Jenkins, GoCD, Spinnaker, and Travis. But which framework is right for your organization? Let's discover what works best for you together!
Tags: continuous integration, continuous deployment, ci/cd, ci-cd, pipelines, jenkins, gocd, kubernetes