Paul Hammant's Blog: Branch By Abstraction Log Jam
The Branch by Abstraction
blog entry is the one I have had most hits for. A couple of weeks
after each new blog entry, it regains its place at the top of my daily
hit count.
ThoughtWorks is consulting at a top-100 US website with Agile, delivery and all that. The client does follow Trunk-Based Development (TBD) and Branch by Abstraction (BBA); Their program of work is big enough to warrant concurrent development of consecutive releases (N.B. I like that way of phrasing the problem). They are getting multiple things from it. One benefit is the ability to engineer larger pieces in parallel, when Agile suggests that you should otherwise try to develop incrementally and not start new releases until previous ones have been put to bed. Another benefit is the hedge-bet that you may not go live with something, or regret it quickly; Refer digg.com's v4 deployment regrets (though that might be because they rewrote rather than refactored).
Anyway, last week two of the awesome senior technical stakeholders on the clients staff were disagreeing in a corridor conversation on what to do next in respect of BBA. It has been successful to date, but they are now dealing with far less concurrent work that they have done at any point in the previous 18 months. There is one larger piece to go live that is dev-complete that we will call 'banana' for the sake of this article. Client stakeholder #1 said that banana team should move back to a real branch (and accept merges; daily if they have to). He said this given that banana was dev-complete, and that other non-banana pieces were methodically being worked on in the BBA style, and that doing one extra --with-banana build just before commit is cumbersome teams who are working on non-banana functionality, if all they get is a notion that they did not break the banana build. Senior Stakeholder #2 said we should stick with the established TBD + BBA plan which suggested that developers should ensure they have not broken other teams builds, by running them just prior to commit.
Nobody wants to merge all the functionality into one build as it removes the hedge-bet side benefit of BBA mentioned above. The ability to not go live with banana is key in my opinion, if the client chooses to keep other benefits but not do banana after all, or delay it for reasons of timings. Thus SCM branches remain alluring. Really busy teams with refactor happy agendas who are not using SCMM 5 level source control tools are going to need to be cautious about the cost of downstream merges.
Anyway, the debate had been going 20 minutes and my drive-by contribution for my friends/clients was:
They're both smart fellows, so after a mere 5 seconds of silence, they said "that will work" in unison and got back to tending their email and alike. Some teams have an extra minute on their build now, but that feels secondary versus the cost of broken builds and roll-backs because the frantic pace of Agile development.
Martin has written again about FeatureToggles which is work reading if you are doing TBD+BBA.
ThoughtWorks is consulting at a top-100 US website with Agile, delivery and all that. The client does follow Trunk-Based Development (TBD) and Branch by Abstraction (BBA); Their program of work is big enough to warrant concurrent development of consecutive releases (N.B. I like that way of phrasing the problem). They are getting multiple things from it. One benefit is the ability to engineer larger pieces in parallel, when Agile suggests that you should otherwise try to develop incrementally and not start new releases until previous ones have been put to bed. Another benefit is the hedge-bet that you may not go live with something, or regret it quickly; Refer digg.com's v4 deployment regrets (though that might be because they rewrote rather than refactored).
Anyway, last week two of the awesome senior technical stakeholders on the clients staff were disagreeing in a corridor conversation on what to do next in respect of BBA. It has been successful to date, but they are now dealing with far less concurrent work that they have done at any point in the previous 18 months. There is one larger piece to go live that is dev-complete that we will call 'banana' for the sake of this article. Client stakeholder #1 said that banana team should move back to a real branch (and accept merges; daily if they have to). He said this given that banana was dev-complete, and that other non-banana pieces were methodically being worked on in the BBA style, and that doing one extra --with-banana build just before commit is cumbersome teams who are working on non-banana functionality, if all they get is a notion that they did not break the banana build. Senior Stakeholder #2 said we should stick with the established TBD + BBA plan which suggested that developers should ensure they have not broken other teams builds, by running them just prior to commit.
Nobody wants to merge all the functionality into one build as it removes the hedge-bet side benefit of BBA mentioned above. The ability to not go live with banana is key in my opinion, if the client chooses to keep other benefits but not do banana after all, or delay it for reasons of timings. Thus SCM branches remain alluring. Really busy teams with refactor happy agendas who are not using SCMM 5 level source control tools are going to need to be cautious about the cost of downstream merges.
Anyway, the debate had been going 20 minutes and my drive-by contribution for my friends/clients was:
Switch all
teams to building the --with-banana build primarily, with an optional
check that the implicit --without-banana build has not regressed just prior to checkin.
They're both smart fellows, so after a mere 5 seconds of silence, they said "that will work" in unison and got back to tending their email and alike. Some teams have an extra minute on their build now, but that feels secondary versus the cost of broken builds and roll-backs because the frantic pace of Agile development.
Martin has written again about FeatureToggles which is work reading if you are doing TBD+BBA.