CI/CD Introduction
During my job search, I keep hearing about this concept called CI/CD. So naturally, that sparked my curiosity! Turns out, CI/CD is a lifesaver, and is widely used by large companies that have a goal of producing new apps and features for their customers. In this article, we will discuss what CI/CD is, it’s different meanings, and learn why it is utilized by so many successful businesses.
What is CI/CD?
CI/CD is a method utilizes to frequently deliver apps to customers through the power of automation in the stages of development. The key points of CI/CD is Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (Also CD). The main purpose of this method is to avoid “integration hell”, which is a term that refers to a situation where the time it takes to integrate code exceeds the time it took to actually write the code.
CI/CD gives the gift of ongoing automation and continuous monitoring through the lifecycle of an application. From testing and integration, to delivery and deployment, CI/CD makes all stages of the application lifecycle a lot more manageable. These practices can be intertwined, and are often referred to as a CI/CD pipeline. They are typically supported by development and operations teams, who work together in an agile way with either a DevOps or site reliability(SRE) approach.
What are the different meanings of CI/CD?
CI = Continuous Integration
Continues Integration is an automation process for developers. It is successful when new code changes are consistently built, tested, and merged to a shared repository. Often times in development, there are too many branches of an app during development, and they often butt heads with one another when merged together. CI is the answer to this problem.
CD = Continuous Delivery and/or Deployment
These two terms are related concepts and can often be used interchangeably. Both automate further stages of the pipeline, but to illustrate just how much automation is happening, they can be used separately.
Continuous Delivery usually refers to changes made by developers to an application that are automatically tested for bugs and uploaded to a repository. Afterwards, they can be deployed to the live production environment by the operations team. This allows communication between the business teams and the developers to be much easier. The main goal is for deploying code to take minimal effort, and Continuous Delivery is a means to this end.
Continuous Deployment usually refers to automatically releasing a developers changes from the repository to production, where it is usable by customers. It relieves the operations teams from being overloaded with manual processes that slow down app delivery. It enhances the benefits of Continuous Delivery by automating the next stages in the pipeline.
The Pipeline
1. Continuous Integration
Build -> Test -> Merge
2. Continuous Delivery
Automatically Release to a Repository
3. Continuous Deployment
Automatically Deploy to Production
CI/CD can refer to just one, or all three of the above stages in the pipeline. In the end, remember that CI/CD is a process that is visualized by a pipeline, and adds a higher degree of the ongoing automation and continuous monitoring to an apps development.
The term really depends on how much automation has been built into the pipeline case-by-case. To start off, many enterprises start by adding CI, then work their way towards automating delivery and deployment down the road.
Continuous Integration
In modern application development, companies typically want to have multiple developers working simultaneously on different features of the same app. However, if an organization merges all the branching source code together on the same day (merge day), the work that comes with it can be tedious, manual, and time-sensitive. The reason for this is because when a developer is working in isolation, their code may work, but when combined with another developers code who has also been working in isolation, it might not work! The size of this problem can increase drastically when each developer has their own, customized IDE, rather than a cloud based IDE used by all developers on the team.
Continuous Integration allows developers to merge their code changes back to a shared branch more frequently, sometimes even daily. When the changes are made to the app and merged, the changes are validated by automatically building the application and running different levels of automated testing. These tests, typically either unit or integration tests, ensure the changes don’t break the app. Because of this, everything is tested. From classes and functions, to different modules that make up the entire app. If the automated testing discovers a conflict between your code and the existing code, it will stop you in your tracks and identify those bugs before it ever reaches production.
Continuous Delivery
Following the automation implemented by the CI step in the pipeline, Continuous Delivery automates the release of that validated code to a repository. In order to have an effective continuous delivery process, it’s important that CI is already built into your development pipeline. The goal of Continuous Delivery is to have a codebase that is always ready to be deployed to a production environment.
In Continuous Delivery, every stage, from the merging of the code to the delivery of production-ready builds, involves test automation and code release automation. By the end of these processes, the operations team is thankful to deploy an app to production quickly and easily, rather than face constant boring, manual procedures.
Continuous Deployment
Continuous Deployment is the final stage of the CI/CD pipeline. It is an extension to Continuous Delivery, which automates the release of a production-ready build to a code repository. This leads to Continuous Deployment, which automates releasing an app to production. Because there is no manual gate at the stage of the pipeline before production, Continuous Deployment relies heavily on well-designed test automation.
In practice, Continuous Deployment means that a developers changes to a cloud application can go live just minutes after writing the code, assuming of course it passes the automated testing. This allows the business to easily receive continuous user feedback, and incorporate bug fixes quickly. All together, these CI/CD practices make the deployment of an application less risky and easier to release changes to apps in small chunks, rather than all at once. The downside to this practice is that there is a lot of upfront investment required, since automated tests will need to be written to accommodate an array of testing and release stages in the CI/CD pipeline.
Conclusion
All-in-all, the CI/CD pipeline makes it much easier for companies to avoid the tedious tasks that come with an applications lifecycle. The upfront cost is expensive, but overall worth it to avoid headaches later on down the line. CI/CD saves businesses from wasting their time, and is widely used for good reason! If you or your company are not utilizing this method, I hope this article has convinced you to change your mind. Keep learning, and happy coding!
