Recommendations From The Build Master
December 11th, 2008
It’s about multi-team configuration management (or continuous integration). It’s from The Build Master .
- Create the mainline (public) and virtual build labs (private) codelines.
- Make sure the mainline is pristine and always buildable and consumable. Create shippable bits on a daily basis. Use consistent, reliable builds.
- Build private branches in parallel with the main build at a frequency set by the CBT.
- Use consistent reverse and forward integration criteria across teams.
- Be aware that dev check-ins are normally made only into a private branch or tree, not the mainline.
- Know that check-ins into a private branch are only reverse integrated (RId) into main when stringent, division-wide criteria are met.
- Use atomic check-ins (RI) from private into main. Atomic means all or nothing. You can back out changes if needed.
- Make project teams accountable for their check-ins, and empower them to control their build process with help from the CBT.
- Configure the public/private source so that multisite or parallel development works.
- Optimize the source tree or branch structure so that you have ONLY ONE branch per component of your product.
You Break It, You Fix It
August 2nd, 2008
(From The Build Master )
This leads to one of the most important rules in the build lab: The build team never fixes build breaks, regardless of how trivial the break is. That’s the developer’s responsibility. We took this a step further: The developer who breaks the build has to go to his development machine, check out the file, fix it, and then go through all the check-in process steps again.
Build Breaks Always Have the Highest Priority for Everyone
This rule means that if you are a developer and you can fix the build break, and the developer who broke the build cannot be found, you should fix it immediately. Afterward, send an e-mail to the developer and the build team explaining what you did to fix the build, and remind your co-worker that he owes you a favor.




