www.Lyngvig.org

Velkommen GæstLog ind
RSS RSS

Navigation

Søg Lyngvig.org
»





PoweredBy

Daily Builds and Build Masters

RSS

Introduction

Many companies were struggling with slipping dead-lines and lack of control of release cycles as projects grew larger and larger during the nineties.  As a result of this, more and more companies began to adopt what is known as a daily build and to this end hired a dedicated build engineer with the title of Build Master.

The Daily Build

The key idea behind the daily build is that the entire product should be built from scratch every day, or more often, so as to ensure that the product is always in a state where is nearly ready for release.  Instead of two or three or more engineers sitting around independently and building their own, private components at irregular intervals, a person is appointed or hired for the sole purpose of continuously ensuring that all parts, from smallest to largest, can be built independently of the developers who are working on these parts.  Such a person is said to be the Build Master: The person responsible for ensuring that the company is at all times in full control of its release cycle so that even if an engineer unexpectedly quits or killed in an accident, the company is still in full responsibility of its release cycle.

The daily build serves as a complete algorithmic (automatic) description of how to reach the stage of deliverables ready for release from the raw computer programming language source code that the software developers are working with.  For instance, a typical contemporary project consists of perhaps two to twenty million source lines of code.  Nobody can memorize and remember that much code.  The job of the Build Master is therefore to ensure that an automatic, functioning, and reliable procedure exists for recreating the RTM files (Released to Manufacturing files) from the bare bone source files that the software developers have created.

Problems

The company that intents to switch to using a daily release build faces a number of challenges:

  • Senior developers who do not like the idea that others are in control of their code (some developers subconsciously or even consciously use their expert knowledge of particular software components in large systems as a ways of securing their job).
  • Developers who do not understand that breaking the daily build (i.e. making it unable to build) is the worst crime that a software developer can at all be guilty of.
  • Management may not understand the benefits of introducing and maintaining the extra cost of a Build Master - even if the company's schedules have repeatedly slipped.

Benefits

Experience has shown over and over again that as soon as a company introduces and sticks to rigorously, automatically tested daily builds, the company gains control of its release cycle and can begin to schedule much more precisely and actually live up to its promises to the public.

Some of the benefits of introducing a daily build system are:

  1. The developers are constantly aware that they may not introduce bugs in the system - in other words, they remember to test their own code.
  2. The testers (Q&A) are given a new product to test each and every day so that they get a very great degree of experience in testing the product.
  3. The management can at any time open up the relevant folder on the company intranet, run a the latest and greatest copy of the product, and see for themselves how usable it is.  This means management no longer operates in the dark and no longer have to rely on a seemingly endless stream of engineering promises of soon and rapid release.
  4. The language translators can get a day for day report of what new translation strings have been added to the product so that they can incrementally translate the product.
  5. Making a beta release is as easy as instructing the Build Master to use a new version number: The rest of the procedure is already fully automated.

All in all, this translates to:

  • The company reduces cost while gaining control and loosing the dependency upon core developers.

It actually turns out that one of the main problems of many large projects is to build it: New developers spend days or weeks figuring out how to build the product.  With a Build Master in the company, the new developer can simply call on him for advice and help on how build the product because the Build Master is the master builder: The sole person who really knows how to build the product from scratch in an automated way.

Rules

The following are some of the rules that apply to daily builds:

  1. Each build is assigned a unique version number, which includes a four or six digit build number.
  2. Each build is built from scratch, relying on as few external tools as at all possible.
  3. Ideally, the build machine itself would be recreated from a disk image for each and every build.
  4. Breaking the build, by introducing compile-time or link-time errors, should be considered very bad and automatically cause the breaker to give donuts.
  5. Each build should produce three things as its output:
    • A set of files shipped to a company intranet server, which are ready to be shipped to manufacturing.
    • A comprehensive report of the build status and result.
    • A certainty that the product is under full control and that no step is outside the mechanical reproduction of a modern computer system.
  6. Once the RTM files have been created, they must be checked into version control so that the company forever retains a copy of all builds made.
  7. The entire build image, i.e. the set of files making up the build, must be burned to DVD/Bluray or stored on magnetic backup media so as to ensure that the company has each and every build available forever after.

Build Master

The primary purpose of the build master is to make himself redundant.  This is done by automating the build process as much as at all possible.  When I worked as a build master, I could literally take a week off without anybody noticing - because the entire system ran automated without my intervention.

Q&A

Some might think that the Build Master is part of the Q&A Department.  Not so.  The Build Master is to the developers what the testers are to the end-user: The warranty that everything works as expected (with respect to building the product).  The Build Master oversees and automates the build of the product whereas the testers oversees and automates the test of the product.

In a normal organization, the Build Master is an independent manager on the level of the Q&A and Engineering managers.  You can say that the Build Master operates his own tiny department, which in some companies encompass dozens or hundreds of build engineers.

Advice

A daily build system should be built using reliable, portable tools such as Python or C# for .NET/Mono.  Sometimes people try to build a build system using Windows CMD.EXE batch files, but this always ends up with a very unreliable and unmaintainable system after a few years: And countless are the hidden errors that are not discovered until some detail-oriented build master takes his or her time to read through the entire (often megabytes) log.

Denne hjemmeside vedligeholdes af .  Copyleft (-) 2010-2012 Mikael Lyngvig.  No rights reserved. Siden hostes på www.UnoEuro.com.