Continuous delivery conversations

Last week I was at the CoDeOSL conference in Oslo. It was an interesting day, with some very good sessions, but as usual it was conversations had in the breaks that were of the most interest. I’d like to describe two discussions that I had that seem, on the face of it, to be in conflict.

Conversation #1

The night before the conference there was a meetup in a bar just around the corner from the conference hotel. I arrived a bit late and tired (because I was still recovering from the ACCU conference which had finished the previous Saturday) and struck up a conversation with Mike Long (who was also recovering from the ACCU conference). We were talking about patterns of interacting with source control that support continuous delivery – specifically the Automated Git Branching Flow that has been proposed by JOSRA.

Mike had an A5 leaflet that described the flow, including the diagram above, but I found that I needed to read the full article on the web before I could start to make sense of it. My distillation of their words is that:

• continuous delivery depends on trunk always being potentially shippable
• merging is always dangerous, so don’t allow complex merges onto trunk
• automate the process of performing trivial, fast-forward merges onto trunk

Adopting this process (using the Open Source Jenkins plugins provided) leads to a flow that requires developers to merge from trunk before pushing their changes. As long as the automated merge to trunk that results from this push is a fast-forward merge, then everything is good. If it isn’t, then the push fails and the developer has to fix the problem locally, before attempting to push again.

Steve Smith voiced some scepticism on Twitter:

Conversation #2

At lunchtime I headed into Oslo to get an anniversary gift for my wife (yes, romantically, I was in Oslo on our anniversary and she was in Scotland). I sat down late to (a fantastic) lunch and grabbed Olve Maudal as he headed back towards the afternoon session. In his presentation, earlier that day, he had talked about the development process that his teams have adopted at Cisco. Nothing is permitted to interfere with the flow of their developers, so when they push onto trunk there is no checking of any kind. Of course, every push results in a full re-build of all binaries and they begin to get feedback very quickly, although it can take some time before the build completes.

Olve’s opinion is that the overhead imposed by the Josra approach is unnecessary, and is an optimisation for the small number of cases where the developer hasn’t done enough checking before pushing their changes: “Give the developers the tools to do the checking before they push and rely on their skill and professionalism to use them appropriately.”

Converging the conversations

Not so long ago I blogged about the debate around whether TDD was a good idea or not and I think that a similar contextual misunderstanding is going on here. The Josra flow is designed to facilitate Continuous Delivery at organisations where protecting trunk from poorly considered commits is more important than preventing any interference of the developer’s flow. Steve and Olve are more concerned with keeping the developer’s flow unhindered, relying on their professionalism to minimise the number of issues (and also quickly fix any issues that do occur).

I’m looking forward to the inevitable discussions, heated and otherwise, that will happen. A taste of what’s in store can already be seen in this tweet from Olve:

But my feeling is that, once again, it’s a case of “whatever works for you”.