Paul Hammant's Blog: The definition of 'The Build' has changed over time
What is “The Build”? Well it has changed over time. On Twitter:
As a dev-team member in 2017, "the build" means what to you?
— Paul Hammant (@paul_hammant) April 18, 2017
Yup, the Twitter intelligentsia takes it to mean the inclusion of build stages, after compile/package. Specifically test automation. At least in 2017 (as the question/poll was posed).
Before 1995, it probably meant just compile and package. Microsoft Secrets (a bestseller with many translations) came out and detailed a way developers worked on a single branch in their SLM (Slime) VCS. Pertinent to builds:
The build was “usually” an overnight thing. The next day (implicitly) a private a release of some sorts for what amounts to desk checking of the feature. Then a suite of automated tests - MS had a tool back then that was highly capable in the UI clicking world. All that was pre-commit, so most likely it was the developer’s own machine building the app (MS Excel was studied for the book) over night. It was a trunk-ish rigor on a single branch, with choreography between developers (and test engineers) to make it work, even if it didn’t say Trunk explicitly.
Then Continuous Integration (CI) happened - pioneered on the C3 project (mid 90’s) by a bunch of the Agile signatories, led by Kent Beck. CI was greatly popularized by Martin Fowler and Matt Foemmel on Martin’s site in 2000. The idea was that you’d really focus on the integratablity of all of the components/modules of the build before checking the commit in, AND you’d attempt to do little commits frequently that met that high bar. Maybe more than once a day (seems like the max for that 1995 MS Excel team). To do that you needed faster builds that the “overnight” reality before. Soon after that epiphany came CI daemons that would watch commits (batches in the early days) that would gard that devs were not cheating in that commit cycle.
And now these days there are sophisticated CI pipelines, designed to communicate breakage as quickly as possible. That might mean contrived build stages (like ‘smoke’) that come before longer stages (like ‘regression’) so that quickest notification of break can be claimed.
“The build” remains something that a developer (or test engineer) can do on a dev workstation pre commit. But the same build is run by CI as soon as possible after the commit is pushed up to the team’s VCS repo.
The days of teams referring to “the build” as the overnight thing are hopefully long gone. Of course, technology enabled all of these speed improvements. Just because Agile teams were stuck in slow VCS in the 90’s doesn’t mean that they couldn’t dream of the speedy per-commit reality of today. I wonder what the future holds.
Fun fact: Co-author of Microsoft Secrets, Michael A Cusumano, wrote The Japanese Automobile Industry (first published in 1985). Lean production with Japanese manufacturers (mainly Toyota) was the theme. His student, John Krafcik, coined “Lean” in an MIT Sloan paper back in 1988 Leanblog article on that.