"Continuous delivery is a software development methodology where the release process is automated. Every software change is automatically built, tested, and deployed to production. Before the final push to production, a person, an automated test, or a business rule decides when the final push should occur. Although every successful software change can be immediately released to production with continuous delivery, not all changes need to be released right away.
Continuous integration is a software development practice where members of a team use a version control system and integrate their work frequently to the same location, such as a master branch. Each change is built and verified by means of tests and other verifications in order to detect any integration errors as quickly as possible. Continuous integration is focused on automatically building and testing code, as compared to continuous delivery, which automates the entire software release process up to production."
Continuous Integration
Continuous integration is the practice of constantly merging development work with a Master/Trunk/Mainline branch so that you can test changes and test that those changes work with other changes. The idea here is to test your code as often as possible so you can catch issues early on. In the continuous integration process, most of the work is done by an automated tests technique which requires a unit test framework. It is best practice to have a build server designed specifically for performing these tests so your development team can continue merging requests even while tests are being performed.
Continuous Delivery
Continuous delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship - this could be UAT, staging or production. The idea behind continuous delivery is that you’re constantly delivering code to a user base, whether it be QA or directly to customers for continual review and inspection. Although similar to continuous integration, continuous delivery differs because it can feed business logic tests where unit tests are unable to catch all business logic, particularly design issues. In this process, you may also be delivering code for code review which may be batched for release or not until after the UAT or QA is done.
The basis of continuous delivery is to have small batches of work continually fed to the next step so it can be consumed more easily and issues can be found early on. This process is typically is easier for developers because issues come to light before the task has left their memory.
Continuous Deployment
Continuous deployment is the deployment or release of code to production as soon as it’s ready. There is no large batching in staging nor a long UAT process before production. Any testing is done prior to merging to the Mainline branch and is performed on production-like environments. The production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button). After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively. Some of these metrics may include revenue, user sign-up, response time or traffic and preferably these metrics are graphed for easy consumption.
The key feature of the continuous deployment process is that it requires continuous integration and continuous delivery because without, you’re guaranteed to get errors in the release.
How They Work Together
Once you’ve moved to a continuous deployment process, you’ll need to have several pieces of automation in place. You must automate your continuous integration build server and continuous delivery to staging, as well as have the ability to automatically deploy to production.
In the ideal workflow, the entire process could be automated from start to finish:
Step 1: Developer checks in code to development branch.
Step 2: Continuous integration server picks up the change, merges it with Master/Trunk/Mainline, performs unit tests and votes on the merge to staging environment based on test results.
Step 3. If Step 2 is successful, developer deploys it to the staging environment and QA tests the environment.
Step 4. If Step 3 passed, you vote to move to production and the continuous integration server picks this up again and determines if it’s ok to merge into production.
Step 5. If Step 4 is successful, it will deploy to production environment.
This process varies slightly based on needs, requirements and approaches.
Continuous deployment relies on small changes which are constantly tested, deployed and released to production immediately upon verification. The ownership of the code from development to release must be controlled by the developer and must be free flowing. The automation of steps allows this process to be implemented and executed without cumbersome workflows.
Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible.
Continuous Deployment follows the testing that happens during Continuous Integration and pushes changes to a staging or production system. This makes sure a version of your code is accessible at all times.
