Do teams really implement Continuous Delivery?

Whenever I changed job I have always encountered the same problem: having a smooth release process, ensuring continuous delivery.

No matter the size of the company, big corporation or startup, and no matter the industry, agency or fintech, it occurred to me that teams were used to accompany their code to production in different “bizarre” ways.

I think the first step towards ensuring continuous delivery and therefore prompt releases, is to organise the workflow. The approach I personally found suitable for most of the cases is gitflow. And this is what I have always been suggesting as soon as taking part of a new team. So far always succeeding, not without difficulties and stress.

But let’s take a step back and talk about the common problems I found in teams.

Thanks to the new technologies, we are able to release some code to production with a very small effort. But what happens in practice? Releasing takes a very long time, because the master branch is not in a clean and therefore releasable state. Even though git has been on the market for several years, it seems to me that engineers are still attached to the svn concept, sometimes even talking about “trunk based development”, where there is clearly a reference to svn.

Nothing against trunk based development if the project has not been released to production yet. You are free to commit directly into master. But many problems if it has. Let’s analyse some of them.

I have been in the situation where I was forced to wait a day before being able to release. The other team members were basically testing their features in the master branch! Sometimes there would be the necessity of releasing an hotfix, which would obviously be impossible without reverting all the unreleased “in-testing” features from master.

In theory this situation could be avoided if everyone would release their commit to master straight away into production. Does it happen in reality? Well, I might have been unlucky, but I still haven’t found a team that does it. Therefore the real solution to this problem would be having a develop (or whatever you want to call it) branch, leaving master always in the same state as production.

Engineers also forget that features tested individually can work really well, but causing issues and edge cases with other features being developed. And here comes in help gitflow again, where you would have a release branch, checked out from develop, deployed on staging, where the team can test the next candidate release with all the features together. Finally, the release branch would be merged into master only when releasing it at the same time.

The common opposition I had from engineers has been: we are an agile team, we do release often and we don’t want to waste time in a new work flow.

Well, what I always pointed out is:

• do you think not being able to release for hours because someone else is testing its own feature on master is agile?
• Do you think being prone to bugs because your feature has not been tested with the others is agile?
• Do you think being forced to revert commits from master because an hotfix needs to be released is agile?

I don’t think so, and luckily I have always managed to contribute improving the workflow, although as I said, not without difficulties and stress.