Continuous Integration (CI)

Continuous integration is a practice that puts the integration phase earlier in the development cycle so that building, testing and integrating code happens on a more regular basis. Developers generally use a tool called the CI Server to do the building and the integration for them. CI requires that all the developers working on a project have Self-testing code. This is code that tests itself to ensure that it is working as expected, and these tests are often called Unit tests. When all the unit tests pass after the code is integrated, both the developers will get a green build. This indicates that they have verified that their changes are successfully integrated together, and the code is working as expected by the tests.

 

Continuous Delivery (CD)

Continuous Delivery means that each time the developers make changes to the code, integrates and builds the code, that they also automatically test this code on environments that are very similar to production. In each different environment, the code that both the developers have individually written is tested differently. This gives more and more confidence to them, and to you, that the code will work on the production environment when the code is deployed there. Crucially, the code is only promoted to (tested on) the next environment in the deployment pipeline if it passes the tests of the previous environment. This way both the developers get the new feedback from the tests in each environment and, if there is a failure, they can understand more easily where the issue might be and get it fixed before the code gets to the production environment.

CICD1
CICD2

The Software Development Pipeline

From a high level, a CD/CD pipeline usually consists of the following very basic and discrete steps:

1.Commit.
When a developer finishes a change to an application, he or she commits it to a central source code repository.

2.Build.
The change is checked out from the repository and the software is built so that it can be run by a computer. This step depends a lot on what language is used and for interpreted languages this step can even be absent.

3.Automated tests.
This is where the meat of the CI/CD pipeline is. The change is tested from multiple angles to ensure it works and that it doesn’t break anything else.

4.Deploy.
The built version is deployed to production.

The entire pipeline should be as automated as makes sense for your organization. Maximum automation would be that a single commit by a developer will automatically result in an update to production a few hours later.