Recommendation from Microsoft’s Software Configuration Management Best Practices

Build Management Recommendation

Recommendation for Defining a Build

• Define terms in your development process, and keep a glossary of them on an internal build Web page. If you like, standardize on the definitions in this chapter.
• Clean build your complete product at least once per week, or every day if possible.
• Use incremental builds on a daily basis if clean builds are not possible or practical.
• Start charting the quality of your product, and post it where everyone involved in the project can see it.
• Release LKG (or IDW) builds weekly; then switch to daily releases toward the end of the shipping cycle.
• Follow the Software Development Flow diagram.

Recommendation for Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work

• 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.

Recommendation for Daily, Not Nightly, Builds

• Hire a consulting firm to come in and review your processes and tools.
• Start your build during the day, not during the evening.
• Publish the build schedule on an internal Web site.
• Release daily builds as sure as the sun comes up, but make sure they are quality, usable builds. Don’t just go through the motions.
• Discourage build breaks by creating and enforcing consequences.

Recommendation for The Build Lab and Personnel

• Set up a build lab if you do not already have one.
• Purchase all necessary hardware, and do not skimp on quality or number of machines.
• Keep the lab secure.
• Show a lot of appreciation for your build team. They have a difficult job that requires a special skill set and personality to be successful.

Recommendation for Build Tools and Technologies

• Use command-line builds for the central build process.
• Use Make or ANT for non-Microsoft platforms or tools.
• Use MSBuild for .NET builds.
• Use VCBuild for non-.NET builds.
• Write your scripts in an easy language such as Perl or Batch files.
• Learn XML because it is ubiquitous.

Recommendation for SNAP Builds—aka Integration Builds

• Develop your own integration build tool to be used as a precheck-in build test to the golden source trees, or wait for Microsoft to release a tool similar to this one. Keep the points in this chapter in mind when you’re building this “silver bullet.”
• If you deploy a Virtual Build Lab process, require that the VBLs use a SNAP system to stay in sync with the Central Build Lab. This is the whole concept of an integration build system such as this.
• Do not rely on the SNAP system as your mainline build tool. Although I mention that some groups at Microsoft use this tool as their Central Build Team build tool, this can be a little problematic because the check-in queues can get really backed up.
• Understand that no magic tool is out there to do your work for you when it comes to builds and merging code. But SNAP is a good tool, and some groups at Microsoft cannot live without it.
• Make sure you have all the other processes down in this book before trying to roll out a SNAP system. These processes include source tree configuration, build schedules, versioning, build lab, and so on.

Recommendation for The Build Environment

Here is a short list of what the build environment example in this chapter is about. If everyone is using the same batch files to launch a build environment, re-creating a build will be less painful.

• Keep the build environment consistent, and control it through the Central Build Team’s intranet Web page.
• Use batch file commands similar to the ones used in the examples in this chapter.
• Enforce through checks and balances in the batch files that everyone is using the published project build environment.

Recommendation for Versioning

What I recommend is to read and re-read this chapter to make sure you fully understand everything in it and to grasp the importance of reliable versioning. Here is a short list of what you need to do:

• Use a four-part number separated by periods for your file version string.
• Increment your build number before starting each build.
• Avoid the use of dates in the build number.
• Use your build number for the label in sources you just built.
• Don’t try to include product marketing versions in your file version string.
• For .NET programmers, don’t link assembly versioning to file versioning.
• During your setup program, do the following:
  • Check for the OS that you are installing on.
  • Avoid copying anything to the system directory.
  • Copy all components to the same directory as the executable.
  • Avoid installing older components over newer ones.
  • Make a copy of any component you overwrite.
  • Use a self-extracting executable to update.

Recommendation for Build Security

With all the talk about security on the Internet and in the applications that are out there, we must not forget about keeping company “jewels” safe. Here are some recommendations that were covered in this chapter:

• At a minimum, use the four-layer approach talked about in detail in this chapter:
  • Physical security— Doors, locks, cameras, and so on.
  • Tracking source changes— The build process.
  • Binary/release bits assurance— The tools process.
  • IT infrastructure— Company-wide policy and security.
• Consider the .NET platform as a means of security.
• Look into software restriction policies that are in Microsoft Windows XP and Windows Server 2003.
• Start worrying about security before a breach occurs.

Recommendation for Building Managed Code

You will find that building projects for the .NET Framework is a bit different than the classic “unmanaged code builds” that have been around before Web services were ever dreamed up. I went over the parts of building .NET code that tend to trip people in this chapter; the following is a quick list of recommendations:

• If you build managed code, learn the basic terms of the .NET Framework and the compilation process explained in this chapter.
• Use delayed signing when developing your project to avoid having to sign the assemblies in conjunction with your daily build.
• Understand the risk of exposing your developer’s machine to external attacks because of the skip verification list that is created when delaying signing.
• Decide what is the most practical way of setting up your solution files for your .NET projects. Then enforce whatever policy you come up with through your CBT.

Recommendation for International Builds

Here is what is done at most of the bigger groups at Microsoft and is thus our preferred way of internationalizing our products.

• Write single binary code as the first step toward truly world-ready products.
• Implementing a multilingual user interface that allows users to switch between all supported languages is the next logical step.
• Write Unicode-aware code and create satellite DLLs for your language resources to make these goals much easier to achieve.

Recommendation for Build Verification Tests and Smoke Tests

Some of the general points of the chapter are:

• Run Visual File Information and VerCheck on each build.
• Establish a quality bar that the build will be measured against
• Let the test team own the BVTs, but let the build team run them.
• Automate BVTs and smoke tests.
• Track BVT results on a public intranet page.
• Know the difference between BVTs and smoke tests.
• Always have the testers or developers run the smoke tests, not the build team.

Recommendation for Building Setup

To improve your setup reliability the following should be done:

• Decide which setup tool you will use: Wise, InstallShield, WiX, or another brand.
• Track all files in your product in a spreadsheet or, better yet, a database. If you are using WiX, the files are listed in the .wxs file.
• Build setup every day, and practice deploying your product to test machines every day. Do not release the build until setup has been created successfully.
• Start pushing the setup responsibility back to the developers who own the modules.

Recommendation for Ship It!

The following list should be done as the final steps to shipping a great product:

• Define what and when shipping is for your group. Follow Jim McCarthy’s Rule 21.
• Start restructuring source trees before you ship, not after.
• Establish a standard release process for your group.
• Release a new build process after you release.
• Add the shipping process time to the product schedule.

Recommendation for Customer Service and Support

From reading this chapter you should understand why you need to:

• Create and invest in a strong support organization.
• Make sure your support group has good paths back to the developers but are not intrusive to them doing their work writing code.
• Outline specific escalation paths in support that give useful feedback to the product group.
• Involve your support group as early as possible in the WAR meetings to discuss impacts.

Recommendation for Managing Hotfixes and Service Packs

A lot in this chapter was specific to VSS, but I think when you read this chapter you can draw parallels to the source code control tool you use and just copy the basic architect. These recommendations can be followed with any source code control tool but is more specific to VSS.

• Use sharing to reuse common code modules.
• Use labeling to isolate and mark different builds.
• Use share and pin with branching to create new minor releases.
• Use cloning to create new major releases.
• Remember: Sharing is the first step of branching.

Recommendation for Suggestions to Change Your Corporate or Group Culture

• Follow the seven suggestions to change or create a successful culture:
  • Involve as high a level of management as you can when rolling out new processes or tools. In fact, have the executive send the e-mail on the new announcement.
  • Hire a consulting firm to come in and perform an analysis.
  • Match company values to what you are trying to accomplish.
  • Do the math.
  • Not worrying about getting fired gives you incredible power.
  • Never take no from someone who does not have the power to say yes.
  • Publish policies, processes, and tools on the intranet!
• If you can’t get 100 percent behind what you are doing, you should find something else to do or somewhere else to do it.

Recommendation for Future Build Tools from Microsoft

Looking into a crystal ball that predicts the future, you should see:

• Adopt MSBuild as soon as possible.
• Start researching VSTS and see if there are tools you can implement in your current build process and future processes.