Understanding Continuous Integration (CI)
Continuous Integration (CI) involves developers regularly merging code changes into a central repository. Automated builds and tests are then run. CI focuses on the build or integration stage of software release. It requires both automation (like a CI service) and a cultural shift (integrating frequently). CI aims to find and fix bugs faster, enhance software quality, and speed up updates.
Continuous Integration focuses on smaller commits and smaller code changes to integrate. A developer commits code at regular intervals, at minimum once a day. The developer pulls code from the repository to ensure the code on the local host is merged before pushing it to the build server. At this stage, the build server runs the various tests and accepts or rejects the code commit. The fundamental challenges of implementing CI include more frequent commits to the shared codebase, maintaining a single source code repository, automating builds, and automating testing. Additional challenges include testing in similar environments to production, providing visibility of the process to the team, and allowing developers to obtain any version of the application quickly.
Diving into Continuous Delivery (CD)
Continuous Delivery (CD) automates building, testing, and preparing code changes for production release. It builds on continuous integration by deploying all code changes to testing or production environments after completing the build stage. Continuous delivery can fully automate workflow processes or partially automate with manual steps at critical points. When appropriately implemented, continuous delivery ensures developers always have a deployment-ready build artifact that passed standardized testing.
Continuous Delivery is not continuous Deployment. One misconception about continuous delivery is that every change committed is applied to production immediately after passing automated tests. However, the point of continuous delivery is not to immediately apply every change to production but to ensure that every change is ready to go to production.
The Role of Continuous Deployment
Continuous Deployment automatically deploys revisions to a production environment without explicit approval from a developer, making the entire software release process automated. This, in turn, allows for a continuous customer feedback loop early in the product lifecycle.
Before deploying a change to production, implement a decision process to ensure authorization and auditability of the production deployment. A person can make this decision, and the tooling can execute it.
Using continuous delivery, the decision to go live becomes a business decision, not a technical one. The technical validation happens on every commit. Rolling out a change to production is not a disruptive event. Deployment doesn’t require the technical team to stop working on the next set of changes; it doesn’t need a project plan, handover documentation, or a maintenance window. Deployment becomes a repeatable process that has been carried out and proven multiple times in testing environments.
Image Credits: GitLab
Article Credits: Adit Modi
Adit is a Cloud Engineer at Digital Alpha | 9x AWS | AWS Community Builder | HashiCorp Ambassador