Monthly Archives: May 2015

Branching and Continuous Delivery video discussion

Following on from my previous post and discussions online, we arranged a Google Hangout to discuss things in more detail. I was joined by Dave Farley, Lars Kruse, Olve Maudal and Mike Long and you can watch the unedited video here:

I don’t think we reached any agreement and after the video ended Olve suggested that we meet again to focus on specific topics, in several sessions. Olve’s suggestions were (paraphrased by me):

pre/post-commit checks and their effect on feedback speed
benevolent dictator/trusted serf as a general model
even more about branching

If you’d like to see more, please Tweet with the hashtag #cdBranching indicating which (if any) you’d like to hear more about.

By |May 20th, 2015|Agile, Continuous Delivery, ContinuousDelivery|1 Comment

BCS: Agile Foundations

Preconceptions challenged
I really wanted to dislike this book, and in some respects I managed to achieve my goal. This is a book published to support yet another spurious agile certification (YASAC?), and I really don’t like that. The authors continuously use ‘Agile’ as a capital-A, noun, rather than the lower-case-a adjective that it clearly ought to be, and I have ranted about that before. And then they resort to anthropomorphising in the fashion “Agile doesn’t say …”, which I find hugely objectionable.

On the other hand, this book does deliver on its claim to provide “a comprehensive introduction to the core values and principles of Agile methodologies.” It describes, without too much embellishment, the fundamental and constituent principles of approaches that support a responsive development process.

The writing is clear and mostly correct, though some things are stated as facts, when they are clearly not. For example:

“There are generally three styles of Agile delivery …”
“A key concept in Agile is emergent or opportunistic design.”
“TDD validates that … the design is appropriate with minimal technical debt”

Broad horizons
This book really triumphs by continually going further and offering the reader broader avenues of discovery. There are continuous references to techniques, approaches and research that go far beyond the usual agile trivia. There’s mention of BDD, Real Options, Feature Injection, Cynefin, Maslow’s hierarchy of needs, Reinertsen’s economic model and Kotter’s 8 stage model – to name just a few.

Some of these are explained in reasonable detail, others are just mentioned in passing, but all contribute to making this book a valuable resource for someone who wants to escape the narrow confines of a typical agile transformation. There’s more to it than stand-ups and planning poker, after all.
Structure
The book is split into 4 sections:

Introducing Agile: A whistle stop tour around the manifesto, that still manages to mention […]

By |May 13th, 2015|Agile, Practices|0 Comments

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 […]

By |May 2nd, 2015|Continuous Delivery, Practices|3 Comments