Run the compiler and linker to build the executables on a daily basis.
This is often known as a NightlyBuild
, because it is automatically performed in the wee hours, followed by automatic running of all the UnitTest
s. People use a SmokeTest
on the build when they arrive every morning to verify that it isn't broken.
One goal is to always leave the source so that the daily build never breaks.
There is often a rule (maybe unspoken) that if the build breaks, everyone on the team has to cease new development until it is fixed.
The book RapidDevelopment
has a chapter devoted to this technique.
In a workshop entitled "Daily Builds Are For Wimps", MichaelTwo?
. One way to put this into practice that has been successful is with CruiseControl
. Another way is with MozillaTinderbox
. See ContinuousIntegrationPatterns
s are not enough, but they can still be useful in conjunction with ContinuousIntegration
to ensure that the whole system is rebuilt from scratch at least once a day, and to establish checkpoints.
One important difference between DailyBuild
s and ContinuousIntegration
is that many DailyBuild
scenarios rely on a BuildMeister
to ensure the clean status of a build. In a ContinuousIntegration
scenario, every developer is responsible for making sure his own check-ins don't break the build (either via email notifications, a status web page, or other method). If he did break it, he is supposed to stop anything he is currently doing and fix the build right away.
Please be aware that in 2004, for 98% of the development projects, DailyBuild
s would be a great advance from the IntegrationHell
in which they choose to live.
At one job, I was specifically told to never do a full rebuild from bare source (i.e., recompile everything). Add my changes and run the makefile. And yes, the code was just as bad as you would expect in that situation.
Is it necessary that DailyBuild
be automated? Lights-out? From bare known configured state? Independent of an IDE?
All of those are highly desirable.
See also: AlwaysBeReadyToShip