|
|
|
|
|
|
|
|
|
MSF for CMMI Process Improvement > Wiki Pages > Activity - Establish Integration Environment
|
Activity - Establish Integration Environment
|
|
|
|
|
|
Activity Information Establish Integration Environment
DescriptionThe integration environment consists of the branching strategy, build naming conventions and criteria, and the computers on which to process builds . Decisions about the integration environment directly affect the efficiency of development and the stability of the mainline of source code. Attributes| Element Categories | [CMMI Track 2] Planning, [CMMI Level 3] PI SP 1.3, [CMMI Level 3] PI SP 1.2 | | When | After significant updates to the solution architecture, typically once at the beginning of each iteration. | | Entry Criteria | Product Integration Plan Complete: The integration sequence and criteria for the project is complete. | | Exit Criteria | Integration Environment Established: The integration environment is established.
Rationale for Integration Sequence Documented: The rationale for the integration sequence is documented.
Support Documentation for Integration Environment Complete: The support documentation for the integration environment is complete. | | Is Required | Yes |
StepsEstablish 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 contents of the source control server 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 the 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, and 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 must 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 business and development needs is necessary for making this important decision. Provide the rationale for the decision. Establish Build Naming Conventions and Criteria:
Decide upon build naming conventions to streamline their use. Establish criteria for the use, creation, and naming of labeled 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. Provide Build Computers:
Provide the appropriate build computer resources to facilitate development. Establish guidelines for regulating and updating their configurations, running automated builds, reserving time for manual builds, etc. Document guidelines.
|
Last modified at 12/19/2007 10:37 AM by Administrator
|
|
|
|
 |
 |
 |
 |
|