Continuous Integration is the practice of continuously integrating the changes made to the project and testing them accordingly at least on a daily basis or more frequently.Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
Enter: continuous delivery (CD), which is the process of ensuring your software is always ready for deployment. It goes hand-in-hand with the DevOps and agile movement. Deployments are available with the push of a button, and rollbacks (when necessary) are seamless.
When your build is fast and well-automated, you build and test the whole system more frequently. You catch bugs earlier and, as a result, spend less time debugging. You integrate your software frequently without relying on complex background build systems, which reduces integration problems.
Behind every great CD pipeline is a well-oiled continuous integration (CI) pipeline. CI is the process of developers pushing code early and often into a code repository for automated integration testing. The idea is that every piece of code sent to the repository will be tested within minutes and flagged if any errors occur. If an error does occur, that now becomes the main priority of the developer.
Without continuous integration, back-tracking errors can be a tedious and time-consuming process, and it’s easy to get lost in the maze of code changes. Integrating as early and often as possible makes it easier to identify where the error occurs. CI also reduces the risk of having errors flare up further down the CD pipeline.
While the specific CI process can vary slightly based on a team’s preference, the essential steps are:
2.Send code to repository
3.Test code
4.Send back errors
5.Fix code
6.Repeat step 2 and 3
Testing Process
Once cleared through the code repository tests, the next step is to send your code to more expansive staging and production tests. Once again, the key here is automation. For an effective CD pipeline, little to no effort should be going into these tests, allowing your team to focus on development in the CI stage. The tests performed through the stage typically include regression tests (making sure the application works) and performance tests (making sure the application works efficiently).
These tests should confirm that your application works as it should and integrates properly with your existing platform. In many cases, teams will have small user groups test deployments in production-like environments. This gives your team explicit feedback from customers.
To Deploy/Not to Deploy
This is where continuous delivery and continuous deployment fundamentally disagree. In a standard continuous delivery pipeline, once your application is cleared through testing and declared ready for deployment, it sits in a deployment queue. It is not deployed until manually done so. On the contrary, in a continuous deployment pipeline, as soon as an application passes through testing, it is automatically deployed to end-users.
Monitor
Just as DevOps doesn’t end for developers after the code is written, continuous delivery doesn’t end once an application is deployed. Inevitably some applications will have errors, despite all of the testing you worked so hard to automate. This is completely normal. Catching the errors early is critical to the well-being of your application and to the user experience.
CI/CD is a devops best practice because it addresses the misalignment between developers who want to push changes frequently, with operations that want stable applications. With automation in place, developers can push changes more frequently. Operations teams see greater stability because environments have standard configurations, there is continuous testing in the delivery process, environment variables are separated from the application, and rollback procedures are automated.
