Today, applying CI/CD is one of the most crucial DevOps practices. CI means Continous Integration, whereas CD can be applied as either Continuous Development or Continuous Deployment. Sometimes the terminology may seem confusing and people talking about them often assume that you know them from the beginning. So, as a developer applying CI/CD for years and having launched a course about the native CI/CD solution of AWS, AWS CodePipeline, I may help you understand these DevOps concepts. In this post, I will discuss what CI and CD practices mean and explain their differences.
Why Should You Apply CI/CD?
The Problem Before CI/CD
As an experienced software engineer, I worked on many projects in the past where business teams brought an idea they were excited about. Then, we developed in an isolated manner in months. We worked alone, programmed, and tested without any feedback from the business side until we finished it.
The success was all by chance. If the business side liked the end product, everyone was happy. But often didn’t and more work needed to be done, delaying the launch more. So, everyone became upset as a substantial amount of effort, time and money were wasted until that time. Moreover, the probability of the business people liking the end product often decreased in proportion to the time the project took.
Anyway. The launch dates were also fantastic. It always happened during weekends or holidays. Often, lots of fruits and pastries were ready for us. When I was a junior developer, I always felt uneasy about these favors from the corporate. They signaled the expectation of the process to be a long journey. Otherwise, why shouldn’t they treat it like a regular day, right? Anyway, I got used to it later :)
Besides, bringing every piece of the software together at the last time was never smooth. I remember being given many last-minute correction jobs to fix the problems faced.
On the other hand, when I worked on a project alone, there were no pastries for me :) But the deployments mostly went smoothly as there was less cooperation and integration involved. Of course, this is not ideal. We need to collaborate with other developers to build great software.
I believe these stories are not uncommon to most of you. But we need to find a solution, right? Nobody enjoys working on an unsuccessful project and even more after the delay.
The Solution as CI/CD
So, people looked for solutions, and today’s popular practices like Agile and DevOps were born. I will not dive into their details. But in short, if you develop in smaller chunks, deploy and get feedback from the business side frequently, you can detect possible problems in a very early phase. So, the chance of your project’s success increases.
To be able to deploy your software frequently, your deployment processes should also be fast. To deploy fast, you need standard, well-tested and repeatable deployment processes, which do not depend on people. So, they should not involve manual processes as they are not repeatable and prone to errors. You can always forget to execute a command or script. It happens.
Hence, applying CI/CD aims to solve these problems. CI/CD brings automation to the deployment process to release new versions of our software fast and frequently. It also aims to achieve this securely and reliably. Now it is time to discuss the components of CI/CD, and let’s start with the CI part, Continuous Integration.
What is Continuous Integration (CI)?
Continuous Integration, or CI shortly, aims to minimize the problems due to bringing large parts of the software together. Developers commit code changes to a source repository several times a day. Today, we primarily use Git for that and remote Git repositories like GitHub, Bitbucket, or AWS CodeCommit, the native Git repository service of AWS.
In every code submission, it is automatically built. So if there is an integration problem due to a library, etc., the build fails. You check the logs, correct your mistake and push it again, triggering a new build. If your fix is successful, the build passes and produces a build artifact. If not, you repeat the process until it does.
This phase is also an ideal place for your unit tests. You can execute them before or after the build as needed. So, if you break a code during the development, you can catch it early and fix it. Of course, by triggering a new build after that.
We call this process a Continuous Integration pipeline. It starts with the source stage, where the pipeline software pulls the code you committed. Then, it continues with the build stage, where the code is built and tested.
As you see, the pipeline is the orchestrator here. The source stage can be triggered from AWS CodeCommit, GitHub, Bitbucket, whichever repository service you use. For the build stage, you can use a build server like Jenkins or a cloud service like AWS CodeBuild. AWS CodeBuild is the native, serverless build service of AWS.
So, with CI, we aim to merge code changes as frequently as possible. Therefore, we can detect integration errors earlier and eliminate them before deployment.
Then, what about CD? Let’s discuss the first version, Continuous Deployment, next.
What is Continuous Delivery?
In Continuous Delivery, we build and unit test our code as in Continuous Integration. But after the build stage, the pipeline produces a build artifact as our deployable candidate. Then, we deploy it to a non-production environment for our next-level tests. This part can include more than one environment. But I will generalize them as the staging environment.
Next, we run our automated integration or end-to-end tests in the staging environment. We verify the build artifact as a valid candidate for production. So, including some load tests may also be helpful. In this way, we can foresee possible scaling issues before the deployment.
After the automated tests, our Continuous Delivery pipeline triggers a manual approval process. It is the last step before production. The business team performs manual user acceptance tests on our software.
Finally, if everything is fine, someone approves the deployment, and our CD pipeline automatically deploys the build artifact to production. Of course, the person approving is most probably from the business side. As developers, we love leaving the decision to push the button to them.
If we compare Continuous Delivery with Continuous Integration, our code is automatically deployed to production after more tests. But we also have a manual approval step just before production. This part is crucial when comparing it with Continuous Development. So, let’s talk about it next.
What is Continuous Deployment?
In Continuous Deployment, the process is almost the same as Continuous Delivery. But there is no manual approval step in Continuous Deployment. After passing all automated tests, a Continuos Deployment pipeline deploys the build artifact to production automatically.
In Continuous Deployment, your testing will most probably continue in production. Applying Blue-Green or Canary deployments can help you deploy to new instances in production and redirect a small percentage of traffic to them initially. Then, you can switch all traffic to the new version or gradually increase the traffic to be more cautious. Of course, monitoring key performance indicators (KPIs) and technical units such as CPU or memory load are crucial here. You can automatically roll back to the previous version if they do not perform well. We can talk more about these topics in an AWS-specific manner in the future.
So, your test coverage must be well enough to perform Continuous Deployment successfully. The advantage is that your deployments do not have to wait for manual approvals. Therefore, your speed and frequency of deployments will increase substantially. So, Continuous Deployment can be described as a matured version of Continuous Delivery.
Conclusion
Continuous Integration, Continuous Delivery, or Continuous Deployment help release our software fast and frequently reliably and securely. How you apply CI/CD depends on your organization. What matters is automating your manual deployment processes. You can start with CI and evolve it to Continuous Delivery as you proceed. Then, as you become more confident in your testing, you can turn your pipeline into Continuous Deployment.
I hope this post helps you understand CI vs. CD. If your applications are on AWS, you can join my AWS CodePipeline Step by Step course on Udemy to learn CI/CD with AWS developer tools. I will be glad to see you there.
Thanks for reading!
Recommendations for more
- My AWS CodePipeline Step by Step Course
- The Phoenix Project, A book by Gene Kim, Kevin Behr, George Spafford
