CI stands for continuous integration and CD is often used interchangeably between continuous delivery and continuous deployment. The scope of what teams end up achieving within each of these varies a lot. Some teams begin with automated testing procedures after code is merged into the main branch, and others might go as far as testing every single commit in the feature branches, while the developers push code daily. Some might deploy to test environments and wait for the QA team to give the green light, and others might deploy every single commit to production – of course, with a lot of automation baked in. Before going any further, let’s detail these three concepts further.
CI is a practice that enables software teams to merge the code from all developers with the least amount of friction. This goal is achieved by running automated tests on frequently created builds. Instead of waiting for a merge day, or the final release, this approach promotes the idea of merging small, building frequently, running tests, locating failures, and raising them to the team before they move further away from any drift.
Continuous delivery is an extension of CI. It ensures that your code is automatically deployed to a staging environment and tested in a way that it’s always available for an immediate production release. This assurance is commonly achieved by starting with acceptance tests, rolling out builds to a production-like setup, stressing them with loads similar to live environments, checking for regressions, and also carrying out integration tests. Next, these builds are marked ready for immediate deployment needs. Stakeholders are given additional visibility and control to roll them out on their own – leading to increased trust and confidence in what the software teams are delivering.
Continuous deployment is the ultimate goal of the entire CI/CD process. Here, the build is automatically deployed into productive environments once it passes all tests, and automatically rolled back, if necessary. The hardest part of continuous deployment is the automated detection of failures and quick rollbacks without any visible impact to the end user. Pushing small changes early is what defines the success of continuous deployment in practice. However, this model of software delivery is often greeted with resistance and is not adopted by organizations since the business prefers a slow rate of deployment to reduce risks.
How does CI/CD enable faster software delivery?
Software developers check in new code in the code repository, which triggers automated test workflows usually owned by tools such as Jenkins, GitLab CI/CD, GitHub Actions, and others. This part ensures quick feedback for the entire team by validating the health of every single commit. In the absence of a CI system, development teams only get feedback when a bigger release is tested by a dedicated QA team. Quite often, it is already very late in the sprint cycle to identify bugs at this stage, which leads to frustration and loss of stakeholder trust. Modern software is mostly delivered as SaaS or mobile applications. Efficient CI practices further ensure that every single commit works the same on multiple browsers and operating systems. This is simply not possible to test on a developer’s local machine.
Once the code passes the CI phase, it is up to the continuous delivery processes to take it further. Here, the code is promoted to production-like environments, which give real feedback about how the new features work. For a lot of teams, it makes sense to give the code promotion controls directly to the stakeholders beyond this point. As you can see, every stage in the CI/CD process builds upon the success of the previous ones. Initial tests done by the CI systems enable better adoption of continuous delivery, which then naturally evolves to a continuous deployment state.
Sometimes, teams do not progress beyond continuous delivery. Let’s see why this happens.