PostHole
Compose
Login
SE Radio 564: Paul Hammant on Trunk-Based Development
Paul Hammant, independent consultant, joins host Giovanni Asproni to speak about trunk-based development—a version control management practice in which developers merge small, frequent updates to a core "trunk" or main branch. The episode explores the technique in some detail, including its pros and cons and some examples from real projects, and offers suggestions on how to get started. The conversation touches on a set of related topics, including code reviews, feature flags, continuous integration, and testing.
Paul Hammant, independent consultant, joins host Giovanni Asproni to speak about trunk-based development—a version control management practice in which developers merge small, frequent updates to a core “trunk” or main branch. The episode explores the technique in some detail, including its pros and cons and some examples from real projects, and offers suggestions on how to get started. The conversation touches on a set of related topics, including code reviews, feature flags, continuous integration, and testing.
Show Notes
Related Episodes
- Episode 133: Continuous Integration with Chris Read
- Episode 400: Michaela Greiler on Code Reviews
- Episode 440: Alexis Richardson on gitops
- Episode 498: James Socol on Continuous Integration and Continuous Delivery (CI/CD)
Links
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Giovani Asproni 00:00:16 Welcome to Software Engineering Radio. I’m your host Giovani Asproni and today we’ll be discussing trunk-based development with Paul Hammant. Paul is a DevOps and continuous delivery expert, architect and coder and who has been coaching software development organizations on trunk-based development as a recommended way of working for over 20 years. He maintains trunk-based development.com and has a book on the same topic. You can find the links to the site and also to the book in the links section of this podcast. These days Paul does spot consulting remotely for teams wishing to get from where they are to trunk-based development. Paul, welcome to Software Engineering Radio. And is there anything I missed that you’d like to add?
Paul Hammant 00:00:57 No, I think you nailed it all and well thank you for having me.
Giovani Asproni 00:01:01 You’re welcome. Well let’s start then. What is trunk-based development?
Paul Hammant 00:01:05 Good question. It is a branching model that we would use with version control for team software developments.
Giovani Asproni 00:01:11 Okay. Then maybe I should ask, what is version control? Can you expand on it a little bit?
Paul Hammant 00:01:17 Version control is a tool we would use to maintain and manage our source files. Typically text, over time towards completion of a project to ship to customers.
Giovani Asproni 00:01:28 So we are talking about tools like Git or sub versions. This kind of tools are for version control. Am I correct?
Paul Hammant 00:01:36 Yeah, for sure. Git mostly today per force. In some places games companies, sub versions still used, but most of the intelligence here wants to use Git these days.
Giovani Asproni 00:01:47 Can I ask you another question about version control before digging deeper into trunk-based development? So, we know that there were different models, like Git is a decentralized model of version control, but in the past used to be more centralized like sub version or before sub version CVS. So, can you tell us a bit more about these two models?
Paul Hammant 00:02:07 Okay. Sub version per force and a few others, you would mostly require a connection to be the whole time to the server that was maintaining the canonical copy for the entire team. Now you could maybe take a flight and keep working on your stuff whilst you’re offline, but it got harder and harder as time goes on to not reconnect with that server for history and things like that. Decentralized Git material in this age allow you to originate everything offline and work for long periods of time without synchronizing, with mothership, the canonical copy. But in enterprises at least they still have that. The aversion upon GitHub that the entire team is pushing and pulling from would be considered canonical, but we have the ability to maintain a longer disconnection from that canonical server.
Giovani Asproni 00:02:55 Basically with the that centralized model, people could work also disconnected and save the history of all their own work locally and then push it to the central repository ones connected again.
Paul Hammant 00:03:07 Exactly that and actually they can rewrite their history before they push that back up. To simplify what to them was 30 commits into one.
Giovani Asproni 00:03:15 What is trunk-based development in this context?
Paul Hammant 00:03:18 With branching model? And you had many choices over the years, but in my opinion it’s the best branching model. It started its life in the nineties, evolved through the nineties into the current timeframe and it remains a persistent high throughput branching model. Sadly we have to keep reteaching to the industry.
Giovani Asproni 00:03:37 We know that nowadays use a different branching model like Git flow or feature some form of feature branchings and things like this. So, what kind of problems trunk-based development solve that those other models don’t?
Paul Hammant 00:03:50 I met a guy some years ago, Frank Compania, I’m not sure if I’ve got his name right and he gave us a quote, branches create distance between developers and we don’t want that. I was quite jealous. It’s a very good quote and I use it a lot now. Multiple branches for development. The longer we keep those branches alive, the more integration pain we encounter later. So, integration is the correct terminology for when we bring a whole batch of changes back into the principle canonical place and that’s merge really if we talk about the actual language of the source control systems. So, the longer we leave it, a week, a month, a year, the worse it gets in that merge, the more we have to coordinate with other people who would be waiting for that or who’ve been actually working elsewhere, and they were divergent over the same time span. The longer we wait, the worse that merge gets. The more confusing an error prone it could be. So, trunk-based is about trying to minimize that amount of time down to the smallest amount of time so we could save a day.
Giovani Asproni 00:04:55 So you just talk about one of the advantages of a trunk-based development that is about merges. So avoid situations where cold changes make the code diverge in different branches for a long time, making the merge of these changes really difficult at some point in the future. But there are also some other total advantages of trunk-based development. So, some people say that feedback and release cycles are faster with trunk-based development. Can you expand on this?
[...]