“There will be hotfixes!” – anonymous
Your release branch plan should be built around your software release vehicles. A release vehicle is how your software is delivered to your customer. The most common release vehicles are the major release, Hotfix and service pack. In a software plus services scenario the names may be different however and the release may be more frequent.
The Advanced branch plan assumes that your software will require concurrent Hotfix, service pack and next version (MAIN). Almost all software servicing have a need for these classes of release so we setup the release branch plan to support these from the very beginning. Note, that all 3 branches are created at the same time to ensure the correct parent child relationship.
A successful release branch strategy enables the following 3 scenarios.
1. Developers only need to check in once based on which release vehicle the change is for (i.e. Hotfixes go into the product Hotfix branch).
2. No need for baseless merges. Create a natural merge path back to main by creating a hierarchal branch structure based on your release vehicles.
3. Reduce risk of regressions. By creating a parent/child branch relationship between main->SP-> and Hotfix branches changes are naturally merged into future release (i.e. Hotfixes merge into the SP branch on their way to main) reducing risk of bug regressions in future releases.
After the release branches are created changes from main should not FI into the release branches. Changes should merge – one way – from release to main. Also, changes should always merge through intermediate branches (i.e. release->HF->Service Pack->main) to ensure that bug fixes remain consistent in subsequent releases.
Note, once you make your final change to your major release (i.e. the release branch in the diagram above) this branch should be set to read only. This branch is retained for compliance purposes only. Since there is no change history in TFS for labels the only sure way to know the state of your sources is to branch and ship your product from that branch.
Your release branch plan should be built around your software release vehicles. A release vehicle is how your software is delivered to your customer. The most common release vehicles are the major release, Hotfix and service pack. In a software plus services scenario the names may be different however and the release may be more frequent.
The Advanced branch plan assumes that your software will require concurrent Hotfix, service pack and next version (MAIN). Almost all software servicing have a need for these classes of release so we setup the release branch plan to support these from the very beginning. Note, that all 3 branches are created at the same time to ensure the correct parent child relationship.
A successful release branch strategy enables the following 3 scenarios.1. Developers only need to check in once based on which release vehicle the change is for (i.e. Hotfixes go into the product Hotfix branch).
2. No need for baseless merges. Create a natural merge path back to main by creating a hierarchal branch structure based on your release vehicles.
3. Reduce risk of regressions. By creating a parent/child branch relationship between main->SP-> and Hotfix branches changes are naturally merged into future release (i.e. Hotfixes merge into the SP branch on their way to main) reducing risk of bug regressions in future releases.
After the release branches are created changes from main should not FI into the release branches. Changes should merge – one way – from release to main. Also, changes should always merge through intermediate branches (i.e. release->HF->Service Pack->main) to ensure that bug fixes remain consistent in subsequent releases.
Note, once you make your final change to your major release (i.e. the release branch in the diagram above) this branch should be set to read only. This branch is retained for compliance purposes only. Since there is no change history in TFS for labels the only sure way to know the state of your sources is to branch and ship your product from that branch.
|
|
0 comments
Post a Comment