Continuous Delivery at MERGE 2014
We had the pleasure of having Jez Humble of Chef and Paul Hammant of ThoughtWorks talk about Continuous Delivery at MERGE 2014. Jez shared the story of Continuous Integration on a Dollar a Day with the audience. I always enjoy how Jez tells it; he certainly makes the topic much more entertaining.
Personally, I’m still surprised that people would rather deal with periodic integrations (which often create painful merges) rather than check into the trunk. Of course this requires having a culture where fixing a broken trunk build is a critical task to be resolved in minutes, rather than left until someone has time to deal with it. As Jez commented, one of the most selfish things a developer can do is leave broken code on the trunk.
You've probably sensed by now that I’m a believer of Trunk-Based Development and making fixing broken builds a priority. It can be challenging to institute the cultural change needed to facilitate that behavior—especially requiring a broken build to be fixed within minutes—but once you have made the change you will probably wonder how you lived so long without working that way. The important takeaway is that rolling back a change is an acceptable, albeit underused, way to fix a broken build.
Getting back to MERGE, our Continuous Delivery panel had a lot of expertise on it, including customers from both hardware and software companies like Intuit, NVIDIA, Tableau Software and Nuance Communications. They agreed that while Continuous Delivery is hard to set up and do initially, the business advantages of being able to build better software faster makes the hard work worthwhile.
Paul Hammant presented on the benefits of Trunk-Based Development (TBD), branching by abstraction and using feature toggles instead of branching. Afterwards, we had a panel discussion on Continuous Delivery, this time around development patterns. I always find discussions between people who believe in TBD and those who don’t to be entertaining. And while there were no panelists that were dead set against TBD, there were some interesting exchanges.
Case in point, storing application configuration as code. A member of our panel pointed out that while this seems like something that is new and not many people are doing it, it's probably a much more common practice than we realize.
One more thing that I must call out and did so while moderating the panel is that many of the companies at MERGE 2014 are probably already doing these “cutting edge” approaches to development, just under a different name. We are all doing some amazing things; just because we don’t use the latest buzzwords doesn’t mean we aren’t doing similar things.
Finally, it’s time we all started thinking about how we can bring the benefits of version control to all users in an organization, preferably without exposing them to the complexity of it. There were customers at MERGE who are working toward this using Perforce Commons, while others like Adidas are taking different approaches. A fun fact is that here at Perforce we “drink our own champagne,” so we extensively use Commons for document version control across the company. I’m perfectly at home using P4V or the command-line, but Commons simplifies my workflow.