What is manual, what is automatic in Continuous Delivery?

Question

I've read lots of articles about the concept on the internet. I thought I got it, but some statements in other articles make me confused.

In order to simplify and clarify things, I'll presume I use Git as VCS, I have only master branch (and feature branches based on it), only production environment, and it is a Node.js project.

Continuous Deployment is clear. Everything will be released automatically.

Continuous Integration is about making sure that changes don't break things in the code base: master. Once a PR is created from the feature branch to master, my CI tool will run tests, lint, style etc. and the PR will be able to be merged once the pipeline passes.

My first question: Is it considered as part of "Continuous Integration" to create a deliverable (a js bundle, a docker image etc.) and push it to a registry once the PR is merged to master? My own answer is, no, it should be part of "Continuous Delivery". Is that correct?

My second question: Do I have to have at least one staging/test environment (and another branch corresponding to this environment) to implement Continuous Delivery? I'm asking that because I read some articles implying that: e.g. https://aws.amazon.com/devops/continuous-integration/ https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

If I create a staging/test environment, will the meaning of Continuous Delivery change? The same article implies that deploying to a test environment is done automatically in Continuous Delivery.

I'm sure there might be different implementations and approaches for CI/CD. To summarize, I'm confused what exactly will be done automatically and manually in Continuous Delivery.

Thanks in advance.

Answer 1

The first thing to do is to define what is meant by "Continuous Integration", "Continuous Delivery", and "Continuous Deployment". They've come to mean different things to different people.

Continuous Integration comes from Extreme Programming, developed by Kent Beck and others. In Extreme Programming Explained: Embrace Change, Beck says this about Continuous Integration:

Integrate and build a complete product. If the goal is to burn a CD, burn a CD. If the goal is to deploy a web site, deploy a web site, even if it is to a test environment. Continuous integration should be complete enough that the first deployment of the system is no big deal.

From an Extreme Programming perspective, Continuous Integration would result in a deliverable, such as a library or package or container in a registry. If the goal is to make the package, that would be sufficient. However, if the team handles building the system, true Continuous Integration would go further and deploy that package or container to an environment. The team would need to define what its goal and deliverable would be - is it a user-facing software system or a package?

Having a well-controlled staging or test environment is almost certainly required when performing Extreme Programming's form of Continuous Integration or what is often referred to as Continuous Delivery today. These practices require that you have confidence in the ability to deploy software to the production environment on-demand. Without deploying it somewhere, preferably to an environment that is sufficiently like the production environment, how do you intend to have the necessary confidence? This only applies to teams building systems, though - teams building packages may be confident by creating a package somewhere and not publishing it.

As far as branching, you don't need a branch-per-environment. You can continue to use trunk-based development (committing straight to trunk or using short-lived feature branches) with releases made from the trunk or branching for releases. If you are practicing XP's definition of CI or Continuous Delivery, each commit to trunk would result in a build created and deployed somewhere. When you decide to go to production, a person would make the decision to promote the artifacts associated with a specific build to production. If you are branching for release, this would be associated with creating a release branch from trunk. Otherwise, it would be promoting a particular commit hash or tag.