This article helps readers draw the distinction between continuous integration, delivery, and deployment

Continuous integration, according to cloud bees is the practice of integrating changes from different developers in the team into a mainline as early as possible, in best cases several times a day. This makes sure the code, individual developers work on doesn’t divert too much. When you combine the process with automated testing, continuous integration can enable your code to be dependable.

For better understanding..

Developer A and Developer B are both working on the features of an e-commerce website.

Life without continuous integration.

Developer A completes the login page, Developer B also completes the registration page, after two weeks.

It is release day,

They both push their code to the project's repository, set it up to run but then they discover an error, the registration page does not have an email field but an email is required on the login page.

How would users use an email to log in when they never registered it? The registration link on the login page also does not successfully redirect to the registration page, it has the wrong URL format.

At this point, they are thrown with various errors that seem overwhelming to resolve

Continuous integration to the rescue!

Continuous integration fixes this problem by ensuring code from different developers are merged to the main branch as quickly as possible, integration is done continuously using triggers or a specified schedule. Automated testing is also carried out to prevent the challenges that occur with integration during release.

After codes are integrated, the next thing is to ensure they run well during production this is where CD comes into play.

Continuous delivery ensures that changes made to the code are deployable even if they might not be deployed at that time.

Deployable means the code runs well in a production environment. Yes, your code could work well during development but fail during production. You can read more about it here .

For example, the first time I deployed a Django web app. I realized that Django does not support serving static files in production, so I had to use a module known as white noise to help serve it. You could imagine the confusion. My code ran well on my localhost just to see errors during deployment. That is why continuous deployment is important to help pinpoint those errors at an early stage to ensure the code is 'deployable'.

Continuous deployment involves the actual deployment or publishing of the code to all stakeholders, users, etc. This ensures that they give feedback at an early stage as to whether the product meets their expectation. The feedback gotten is implemented by the developers as soon as possible.

The recurring term between these three is 'continuous' that is integration, deployment, delivery have to be carried out using a specified schedule or trigger ( commits, push, etc). The idea is to ensure that the time between the actual code change and deployment, integration, and delivery is short enough to reduce overwhelming errors as well as facilitate easy detection of bugs or unsatisfactory features.