Combating the Tools Cult

The above is true in many scenarios, including Continuous Delivery. Let us look at an example.

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

As per the above definition, it is not Continuous Integration if you are not integrating at least once in a day to mainline (aka trunk). Instead, it is called CI Theatre which means:

• Running CI against a shared mainline but with infrequent commits
• Allowing the build to stay red for long periods;
• Running CI against feature branches which result in continuous isolation

Using the Continuous Integration tools — Jenkins , Circle CI, Wercker, Codeship, Bitrise does not mean “doing CI”.

Commits as communication

Commits are the way to communicate between the developers. The timely communication is missed out when the commit is delayed or by committing to a branch. And the tooling is not essential for doing Continuous Integration. Read Continuous Integration a Dollar a Day, to see how to “do CI” with an old machine and a rubber duck.

The Feature Branching makes sense for Open Source where a more rigorous process is required to look at what goes into the codebase. In an organisation where you know everyone who commits code, stringent commit policy may not be necessary.

Continuous Delivery as a Cult

Using Kubernetes or Docker or having a lot of automation doesn’t consider as “doing continuous delivery”.

Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.

The key is safe, quick, sustainable releases. If the code is getting stuck for integration or merging, it is Discontinuous Delivery. Aim for Operability.

Wrong branching strategy

I got a chance to listen to Alain Hélaïli about End to End Agility @ Github. He emphasised that the branches are short-lived @ Github than the complex, long-lived branches as shown above. And they deploy 50 times a day to production. But it is sad to see ignoring “short-lived” and following the Github flow which kills the purpose.

I also heard about an organisation installing a daemon on every developer machine to delete uncommitted changes. That will be fun :)

An Updated version of an earlier published post — Are you doing CI or CI Theatre?