Branching Configuration Management Projects Overview
Branching projects is useful for:
• extracting and building from previous versions of a project
• building customized versions of a product
• performing branch development work
• performing post-release maintenance
• fixing defects in previous versions of the product
• testing new features outside of the main development path
• experimenting with research that does not affect regular development
You create a project branch by creating a new development path.
There are main models to follow when branching projects:
• release based branching
• project based branching
Release Based Branching
In a release based branching model, the content of the project (features, enhancements, and defects) tends to be static and well defined. Typically, the complete project goes through the stages of development, testing, and release.
All development activity is performed on the main trunk of the project. Release candidates are identified as checkpoints and finalized on a project branch. Bug fixes and stabilization development work continues on the main trunk of the project and are migrated to the release candidate branch using Apply Change Package.
This type of branching model is suited for development environments where full versions are released into production. When using this model, it is recommended to limit the number of branches to avoid the need for mass merges at a later point.
Project Based Branching
In a project based branching model, the content of the project (features, enhancements, and defects) tends to be dynamic, with constant additions and removals of subprojects (comprised of features, enhancements, and defects) until the last minute. The project is released in increments into production. Usually, this type of development does not release the entire project after the initial rollout, and tends to have updates to production as frequently as every week.
All development is performed on project branches created from the latest production checkpoint. Changes made on project branches are merged into an integration branch using the resynchronize change package command and tested on that branch before being merged into the main trunk. After newly introduced integration code has been released on the main trunk, all active project branches are dropped and re-created from the latest main trunk (production) checkpoint. This forces all active project branches to synchronize with the latest production release.
In a project based branching model, it is recommended that you only create branches for concurrent or parallel development projects. Creating branches at the feature, enhancement, defect or task level is not recommended.