1

Establish Branching Strategy

• Establish a strategy for how code is integrated into the mainline of source code. Software configuration management tools enable complex branching from and merging to the mainline code, as well as between branches. A clearly thought out and documented branching strategy is essential to the success of the project.  
• Different strategies have their strengths and weaknesses. For example, a small software company that is working on a first version of a product might choose to do all of their development directly off the mainline. This creates instability throughout most of the development period. While this might work for this company, it would not work for a company that has multiple versions of product in either maintenance and/or development at the same time.
• One possible strategy is to copy the entire source control repository and work in parallel. While this avoids the complexity of branching and merging, it does not take advantage of software configuration management tool capabilities. It also requires twice the work.
• Another strategy is to use promotion group branches. Promotion groups are branches that represent different states of the code. A separate branch is created for development, test, and production-ready code. The code is “promoted” to the next state as it meets defined criteria.
• Yet another strategy is to create multiple working branches off of the mainline. Branches are merged to each other, to mainline, and/or receive back merges from mainline, as needed. It may be necessary to create such a complex branching strategy to meet development and business needs. For example, consider an organization with a product that has just released a major version, which is now in maintenance mode; is developing two future versions, each with several complex features, some of which will take several months or longer to develop; and is preparing for a trade conference in a month where a working build with an unreleased feature will be showcased. This company needs to keep its mainline and some of its branches extremely stable. While the maintenance using this strategy is more rigorous, it is warranted by the business needs.
• A profound understanding of the of the business and development needs is necessary for making this important decision. Provide the rationale for the decision.

2

Establish Build Naming Conventions and Criteria

• Decide upon build naming conventions to streamline their use. Establish criteria for the use, creation, and naming of label builds. For example, if a build is meant to go outside of development for evaluation, and will not be changed or modified, it should be labeled. Document conventions and criteria.

3

Provide Build Machines

• Provide the appropriate build machine resources to facilitate development. Establish guidelines for regulating and updating their configurations, running automated builds, reserving time for manual builds, etc. Document guidelines.

The integration environment is established.

The rationale for the integration sequence is documented.

The support documentation for the integration environment is complete.