Comments on: The Cost of Integration http://www.conifersystems.com/2008/11/29/the-cost-of-integration/
Mon, 08 Dec 2008 17:33:16 +0000
hourly
1 https://wordpress.org/?v=5.2.1
By: The Cost of Branching - Conifer Systems http://www.conifersystems.com/2008/11/29/the-cost-of-integration/#comment-79
Mon, 08 Dec 2008 17:33:16 +0000http://www.conifersystems.com/?p=78#comment-79[…] wrote previously on the cost of integration. I’d like to follow up by discussing a related topic, the cost of […]
]]>
By: Matt http://www.conifersystems.com/2008/11/29/the-cost-of-integration/#comment-76
Mon, 01 Dec 2008 19:06:22 +0000http://www.conifersystems.com/?p=78#comment-76Hi Eric, I agree that as teams get larger we are stuck making a choice between several less-than-satisfactory alternatives.

However, I’ve worked on projects with well over 100 people regularly committing to a single branch without stability problems. I think it’s a matter of having appropriate tools to (1) detect regressions promptly and (2) prevent regressions from happening in the first place.

My guess is that teams that only focus on “detection after the fact” rather than prevention are the ones whose processes start breaking down around ~100 engineers.

Computers (especially headless desktop PCs) are so cheap these days; compare the cost of buying an appropriately sized build farm to the cost of hiring an engineer. It’s a bargain if it saves you any time at all.

I tend to agree, but I think as teams get large (an agile anti-practice I’d argue) and you have 100 people committing into the same large code base, the “everyone works on trunk” ideal starts to break down. Especially as the rate of commits times the length of the build, exceeds the capacity of the system to quickly build each commit.

In these circumstances, my favorite answer is to split the team of 100 up into component teams and build parts of the system separately. When that can’t be done, I think feature or component streams may be the least evil remaining option. I say streams rather than branches, because stream based SCMs actually allow for automatic merging from the main integration “branch” back into the ones developers are working on.

The big bang integration risk is still present, but builds off the feature streams may be independently verifiable and integrated into the integration stream at least daily. It seems like a reasonable compromise.

That said, it’s still far from ideal and you’re dead right that the cost of integration increases over time.