[jasonallen]

It reminds me of an old story about Microsoft Windows. Back in the early 2000's, compiling and building Windows from source code took many hours on very specialized build hardware. Meanwhile there were thousands of developers who contributed to the full Windows stack. If any developer checked in a build failure, it would cause the build to be delayed. Well, at that scale (of thousands of developers), you can't compile Windows even if devs only commit 1 build break per year. Bad times...

[InclinedPlane]

There was essentially instability and chaos in the big dev heavy divisions at MS when they all worked in one branch, but that led very rapidly to more sophisticated models with more points of validation between the average dev and the common code/builds that qa and everyone else shared and used.

[lolive]

The common pattern nowadays is to code review each commit, build each commit on Jenkins & pass tests, git bisect, etc... What was the procedure back then ?

[tscs37]

"don't break the build" was the procedure.

[lolive]

amen!

[InclinedPlane]

Do you mean before or after? Before, it was "do your best", which was never enough, not with everyone partying in the same branch. After, it was a matter of breaking things up into different feeder branches down to individual teams. Code that goes "up" into more mainline branches is required to have a higher QC bar in order to get in, such as a full clean build of the entire set of sources (which for something like windows, office, or visual studio / .net could take a very long time) and running the entire set of build verification tests with zero failures (also a long process). Code would go up during an integration window, there would inevitably be some instability that would need cleaned up (test failures, maybe code breaks sometimes) which would get stabilized, then code would flow back "down" to individual teams from those good builds. And code would flow up further into other branches that would be shared and used by more teams around the division/company.

Most dev groups these days use different systems because they tend not to have such monolithic projects, they can leverage automation better, and it's rare to have literally thousands of devs all working on the same software. When you can only get a few builds out per day, or maybe only one, then you have to become a lot more careful at keeping a separation between devs coding away at their desktops and the builds that everyone else depends on.

[Minikloon]

If the bar is set at breaking the build once a year, sounds like we're all average devs.

[stavros]

Speak for yourself, I'm an abysmal dev by that metric.

[optimuspaul]

If I haven't broken a build in any given day you know I haven't written any code that day.