The CI pipeline (Continuous Integration) helps developers continuously test their code, “integrating” it into the application. It answers “Does my new code work?” and “Does it break anything?”.
A CD pipeline (Continuous Delivery or Deployment) is a little more complex. It runs after a CI pipeline and goes a step further with new code: after the CI checks if it integrates well and succeeds, the CD will deliver it to higher environments.
Continuous Delivery and Continuous Deployment are also slightly different concepts. Let’s see below how they differ:
After the CI routine runs successfully in the development house, we want the CD pipeline to deliver the lamp to the test house so we can continue with our testing.
Afterwards, the Continuous Delivery pipeline will wait for us to manually trigger or manually approve deployments to production, i.e. actually adding the lamp to the rich family’s house, only when I am fully convinced I want to do so. It will therefore leave us some human control over the final steps of deployment to production, to perhaps be able to abort or postpone, if we decide to do so.
Deployments from the testing environment and to production via a Continuous Delivery pipeline are usually grouped in ‘releases’: a branch of our repository with many new features that are tested together, to deal with fewer but bigger deployments.
A Continuous Deployment pipeline instead, would leave us zero manual tasks to do, once our new device has been tested and works. However, this would also give us less control over confirming that we want to deploy it to production.
It would, this way, scrap the idea of a ‘release day’ (deployment to production day), to automatically continuously deploy every change that passes the tests in testing and pre-production, all the way to production.
Commenti