| Continuing the discussion from Chapter 1, "Defining a Build," the following are additional build definitions that are good to standardize on. In keeping on the theme of "speaking the same language," look over the terms and how they are defined here even if you are familiar with them. This will keep us in sync. Source code Files written in high-level languages such as C# that need to be compiled (for example, foo.cs). Source(s) All the files involved in building a product (for example, C, CPP, VB, DOC, HTM, H, and CS). This term is used mostly as a catch-all phrase that is specific not only to source code files but to all the files that are stored in version tracking systems. Codeline A tree or branch of code that has a specific purpose, such as the mainline, release line, or hotfix line that grows collectively. Mainline or trunk ("The Golden Tree") The main codeline of the product that contains the entire source code, document files, and anything else necessary to build and release the complete product. Snapshot A specific point in time in which the sources and build are captured and stored, usually on a release or build machine. Milestone A measurement of work items that includes a specified number of deliverables for a given project scheduled for a specified amount of time that are delivered, reviewed, and fixed to meet a high quality bar. The purpose of a milestone is to understand what is done, what is left to do, and how that fits with the given schedule and resources. To do this, the team must complete a portion of the project and review it to understand where the project is in the schedule and to reconcile what is not done with the rest of the schedule. A milestone is the best way to know how much time a portion of the project will take. Code freeze A period when the automatic updates and build processes are stopped to take the final check-ins at a milestone. Public build A build using the sources from the mainline or trunk. Private build (also referred to as a sandbox build) A build using a project component tree to build more specific pieces of the product. This is usually done prior to checking in the code to the mainline. Branching A superset of files off the mainline taken at a certain time (snapshot) that contains new developments for hotfixes or new versions. Each branch continues to grow independently or dependently on the mainline. Forking Cloning a source tree to allow controlled changes on one tree while allowing the other tree to grow at its own rate. The difference between forking and branching is that forking involves two trees, whereas branching involves just one. It is also important to note that forking or cloning makes a copy (snapshot) of the tree and does not share the history between the two trees, whereas branching does share the history. Virtual Build Labs (VBLs) A Virtual Build Lab is a build lab that is owned by a specific component or project team. The owner is responsible for propagating and integrating his code into the mainline or public build. Each VBL performs full builds and installable releases from the code in its source lines and the mainline. Although the term virtual is used in the name of the labs, don't confuse it with Virtual PC or Virtual Machines because the labs are real physical rooms and computer boxes. It is not recommended that you use Virtual software for build machines except possibly for an occasional one-off or hotfix build. This concept is explained in Chapter 4, "The Build Lab and Personnel." There is usually a hierarchy of VBLs so that code "rolls up" to the mainline or trunk. For example, let's say that you have a mainline, Project A is a branch off of the mainline, and Developer 1 has a branch off the project branch. Developer 1 has several branches off his branch, with each branch representing a different component of the product. If he wants to integrate one of his branches into main, he should first merge his changes with all the levels above the branch to make sure he gets all the changes. Alternatively, he can just roll the changes into main, which sits higher in the hierarchy. This will become clearer in the next couple of pages. Reverse integration (RI) The process of moving sources from one branch or tree to another that is higher in the VBL hierarchy. Forward integration (FI) The process of moving sources from one branch or tree to another that is lower in the VBL hierarchy. Buddy build A build performed on a machine other than the machine that the developer originally made changes on. This is done to validate the list of changed files so that there are no unintended consequences to the change in the mainline build.
To answer the question on how this topic relates to builds, I would like to borrow a quote. In a paper read at the Eighth International Workshop on Software Configuration Management in Belgium in 1998, Laura Wingerd and Christopher Seiwald reported that "90% of the SCM 'process' is enforcing codeline promotion to compensate for the lack of a mainline." This quote was taken from Software Configuration Management Patterns by Stephen P. Berczuk with Brad Appleton. The book offers an outstanding explanation of how to develop your branching model for your source trees. I agree that if you do not have a mainline to build your product from, you will encounter all kinds of delays in shipping your code that do not seem directly connected to source tree configuration, such as trouble deploying hotfixes (more on this in Chapter 16, "Hotfixes or Patch Management"). By creating a mainline or golden source tree, you will have fewer build errors, because any potential breaks are caught before the reverse integration (RI) merge into the golden tree. Developers can work on different versions of a product simultaneously without affecting other components. These are the two biggest advantages to moving to a process like this among the other main points mentioned in the introduction. Microsoft Sidenote: The Code Just Went Golden! Do you know where the term "golden bits or tree" comes from? In the old days when a product was at its final stage and ready to be released to manufacturing (RTM) to be packaged on a CD, a golden master was created. A golden master was a set of discs sent to the Product Release Services for massive duplication, packaging, and deployment to resellers. The term golden master was a morph of the CD manufacturing term glass master, in which the 24K gold reflective layer of the CD was sandwiched between two glass pieces to provide optimum copying of the discs in the manufacturing process. Hence, when we shipped a product, it went "golden." It was expensive for Microsoft to recall the bits at this point, not to mention a PR (public relations) disaster/embarrassment. Today we still use these terms, but with a little variation. We release a lot of Web Services/applications online, such as Media Player, MSN, Passport, and Windows Update. With these products, we say released to Web (RTW) instead of RTM, or we say golden bits instead of golden master. The golden tree is where the golden bits sources are stored. |
|
