If you cannot release it now, it’s not continuous delivery!

Last year I was thinking hard about why are we using so many terms in the wrong context without properly understanding their meaning and how these turn into “buzzwords”.

Continuous integration, deployment, and delivery — all being part of it.

These three are the topic of this article. It always surprises me how complicated the release process can be and how the efforts to move towards the continuous delivery approach sometimes lead you in the opposite direction.

Let’s look into the main things companies are doing wrong in these areas.

Fail #1 Release team

Introducing the release manager/master position within the company connected to the conventional development creates operational conflict of interests. Why is this wrong?

Many people involved, layers of approvals, tenacious manual testing sessions, …presence of such things in the release process will always cause delays in case something unusual happens — and it will.

The developer must be the one responsible for the end-to-end delivery of the code — from the coding to the production deployment. Otherwise, things are getting too complicated for several reasons.

What happens when something goes wrong during the staging process? Who should take care of it with so many people involved in the process? How much time is consumed by all the communication around this situation and its resolution? My guess is — a lot.

Of course, introducing a coordinator might seem like an obvious solution, but you’ve only added a new layer of dependency and ultimately point of failure.

Fail #2 Git Flow

Another huge issue on the journey to continuous delivery is the fact that most of the companies are using standard GIT Flow where a lot of potential problems are postponed to the code integration — merging the code. You should be practicing continuous integration as an enabler for continuous deployment.

When the feature implementation is taking more than a few days you will probably hear this on your next daily standup:

“I’m done with the implementation, but I have to resolve conflicts”

In my eyes, this means you are not done, your code is not ready for the deployment and became potentially faulty after you merge it. Meaning it has to be tested again. That doesn’t sound simple, fast, or transparent to me!

The whole point of continuous delivery is to deliver and deploy independent software components fast and frequently using dev teams that work in parallel. Trunk-based development is the way to make it easier but it doesn’t mean that everything should go directly to the trunk/master/main branch.

Sometimes it can be useful to use a feature branch. But it has to be a short-lived branch, ie. max a few days old, and immediately merged once the development is stable enough back to the trunk/master/main branch. In the end, if the build, test, or deployment pipeline fails it means you stop. You correct it and learn from it for the future. You are doing this in the production environment so why you are not doing the same in other stages of your delivery environments?

Fail #3 Creating obstacles to give a false sense of security

You are probably familiar with the proverb: “Too many cooks spoil the broth”. Why I’m mentioning this? Sometimes we are putting a lot of obstacles by required code reviews before the integration — merge of produced code. The worst-case scenario is to have a group of global code reviewers who are forced to review every single line of code before the integration takes place. This is so wrong in the context of CI/CD plus it doesn’t make any sense. You should leave this to the pipelines and automation.

You should put trust in your developers from end to end. If you can’t — you are doing something wrong when selecting people for your team

Because how you can ask developers to have end-to-end responsibility if you don’t trust them? Don’t get me wrong — this doesn’t mean that there is no place for code reviews, but again, it should be done before the integration process and without strict limitations which are interconnected with a “global code review” team, blocking rules, etc.

Fail #4 Belief in buzzwords

Similar to how a few years back whole community failed to recognize and implement the agile correctly, we’re now in the midst of yet another scenario like that.

What about the magic buzzwords like DevOps, SRE, and so on? These create another false sense of safety and cause most companies to do mistakes if approached wrong.

The idea that adopting DevOps means adopting continuous delivery as well is simply wrong. And is also a big mistake — DevOps is a cultural concept. Whereas continuous delivery is the defined process used to ship software faster. Adoption of DevOps culture is an enabler towards adoption of continuous delivery, nothing more. You should always keep this in your mind. If you have introduced things like SRE, DevOps, or platform team in your company they have no responsibility interconnected with the delivery of other teams. They are participating only by providing pipelines, tools, platform as a service, etc.

Overall…

It's not that complicated, if you want to reach the real CI/CD state you should be aiming to release now, not tomorrow or in a week…