What is CI/CD?
An intro to Continuous Integration / Continuous Deployment
Definition
CI/CD stands for Continuous Integration / Continuous Deployment. It is a method of developing applications that involves continuous monitoring and testing, and deployment via automation. Changes and updates are able to be continuously shipped to production. This pipeline carries the app through the entire lifecycle from development to production and then is repeated indefinitely as the application grows and changes.
The Old Way
Let’s take a look at how development practices used to work. Say we have two developers, Sam and Jordan. They both have the same starting code pulled down from an SCM (Source Code Management) system like GitHub. Sam is working on a different feature than Jordan. They both write extensive amounts of new code and change multiple lines of the same original code to totally different things. A predetermined code integration day would be a part of the development lifecycle when all the code would be merged into the main repo. Of course, we would get numerous merge conflicts due to everyone working on the same code for so long without any merging. Add on more developers to this team, repeat the process, and we are now in “merge Hell”. After all of the merge conflicts are finally resolved, the code is built. However now the build fails, and we have a massive amount of new code that will have to be sorted through to find what is causing the application build to fail. How can we improve upon this old system?
Continuous Integration
Rather than viewing merging as a phase in the software development lifecycle, the practice of CI has developers merging on a more frequent basis, perhaps even daily. The changes from the developers are being monitored by an automated system that is constantly building and testing the code. The code is run against unit and integration tests and then merged if there are no errors. If a build fails to compile or if any tests fail, the developer will be notified of the errors. This allows developers to be much more effective and efficient in their practice.
Continuous Delivery / Deployment
Continous delivery expands upon continuous integration. After the code has been compiled successfully and merged, it is delivered to another environment where more tests (i.e. User Acceptance Tests, QA) can be run against the build. Once passed, the application can finally be deployed to production. Once the application is deployed to the user, continuous improvements and updates now have a reliable pipeline that they can quickly traverse for deployment to the user. If the build fails, the previous working version of the build will be available to use in production, and the team will be notified of the current build’s failure. This ensures there is a safety net, or a backup, for the code that is running in production. Depending on the team you are working with, the order and responsibilities of these stages will vary, just know that continuous delivery and deployment are not the same thing.
The CI/CD Pipeline
This is the path that our application travels through, from early development all the way to production. Think of it as an infinite loop that is repeated over and over. This pipeline increases developer productivity as they are not constantly dealing with merge conflicts and bugs. Developers are also getting constant feedback about the code as it is being tested very often. Once the application reaches the user, continuous improvements and updates now have a reliable pipeline that they can quickly traverse and be released into production for the user. The key to all of this is automation, and there are many, many different tools to configure your environment with.
Tools
There are many different tools that can be used in different steps of the CI/CD process. If automation is the “nail”, then these are the “hammers”: GitHub Actions, Jenkins, Circle CI, AWS CodePipeline, and Travis.
