Branch Plan – quick start
“Save your creativity for your product… not the branch plan.” – anonymous Below are three branch plans that represent Basic, Standard and Advanced software development projects. The elements of these plans are additive so starting with the Basic plan will allow you to transition to the Standard plan if your product becomes more complex. The most common reason for adding complexity to a branch plan are additional release vehicles (i.e. Service Packs and Hotfixes). Additional release vehicles will require a branch plan that supports concurrent development for each of these. Minimizing the number of release vehicles is the key to keeping your branch plan simple. The goal of the Basic, Standard and Advanced branch plans presented below is to cover most customer branching scenarios. Please post your scenarios not covered below to the community section associated with this document at http://codeplex.com/TFSBranchingGuideII. Our hope is to leverage the Codeplex community to cover alternative (but still valid) branch cases.
Basic Branch Plan
Below is a basic plan that enables concurrent development for your next release, a stable main branch for testing and a release branch for any ship blocking bug fixes. Multiple development areas are supported by creating additional development branches from main.
These are peers to each other and children of main. Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of main and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of main).
Once the release branch is created main and the development branches can start taking changes approved for the next product release.
The Basic branch plan will work well for your organization if you meet some of the following criteria:
1. You have a single major release that is shipped (i.e. a single release vehicle) to customers.
2. Your servicing model is to have customers upgrade to the next major release.
3. Any fixes shipped from the release branch will include all previous fixes from that branch.
Key elements of this plan include
1. DEVELOPMENT (dev) branches for next version work.
a. Focus on wide, flat branches to enable steady code flow to MAIN and then back to peer DEVELOPMENT branches
b. Work in DEVELOPMENT branches can be segregated by feature, organization, or temporary collaboration.
c. Each DEVELOPMENT branch should be a full branch of MAIN.
d. DEVELOPMENT branches should build and run Build Verification Tests (BVT’s) the same way as MAIN.
e. Forward Integrate (FI) with each successful build of MAIN
f. Reverse Integrate (RI) based on some objective team criteria (e.g. internal quality gates, end of sprint, etc.).
2. RELEASE branch where you ship your major release from.
a. RELEASE is a child branch of MAIN.
b. Your major product releases from the RELEASE branch and then RELEASE branch access permissions are set to read only.
c. Changes from the RELEASE branch RI to main. This merge is one way. Once the release branch is created MAIN may be taking changes for next version work not approved for the release branch
d. Duplicate RELEASE branch plan for subsequent major releases.
3. Changes should be checked into one branch only
a. All branches have a merge path back to MAIN.
b. No need for baseless merges.
Standard Branch Plan
As you add additional release vehicles you may need to create additional branches in the production/release area to enable concurrent development. The Standard branch plan below introduces a new release branch to support an additional release vehicle. Most organ
izations will call this a servicing branch to enable development of Hotfixes and Service packs.
This plan will work well for your organization if you meet some of following criteria:
1. You have multiple ship vehicles (e.g. major release and additional service packs for that release).
2. You want to enable concurrent development of service pack and next version products.
3. You have any compliance requirements that require you to have an accurate snapshot of your sources at release time.
All of the guidance any key points from the Basic plan applies to the Standard plan. The Standard plan has these additional items to consider.
RELEASE branches for release safekeeping and Service Pack work
1. RELEASE tree (i.e. SP and RELEASE) are branched from MAIN at the same time to create MAIN->SP->RELEASE parent/child relationship.
2. Product releases from the RELEASE branch and then that branch is changed to read only.
3. Servicing changes are checked into the Service Pack (SP) branch.
4. Changes SP branches merge one-way to MAIN (SP->MAIN).
5. Ship stopping bug fixes checked into the release branch should merge back to MAIN through the SP branch (RELEASE->SP->MAIN).
6. Duplicate RELEASE tree plan for subsequent major releases.
Advanced Branch Plan
The Advanced plan is for products have must support many release vehicles and servicing scenarios. The plan allows for concurrent development of a major release, service packs, Hotfixes and next version work.
All of the guidance any key points from the Basic and Standard plans applies to the Advanced plan. The Advanced plan has these additional items to consider.
1. RELEASE branches for release s
afekeeping, HOTFIX and Service Pack work
a. RELEASE tree (i.e. SP, HOTFIX, and RELEASE) are branched from MAIN at the same time to create MAIN->SP->HOTFIX->RELEASE parent/child relationship.
b. Product releases from the RELEASE branch and then that branch is changed to read only.
c. Check-in based on which release the change applies to (e.g. Hotfixes are checked into the HOTFIX branch).
d. Changes in HOTFIX and SP branches merge one-way through intermediate branches to MAIN (HOTFIX->SP->MAIN).
e. Duplicate RELEASE branch plan for subsequent major releases.
The plans above covers the majority of software development activities. Using these plans as a base will enable your teams to spend more time on developing high quality code and assures that each branch has a specific role. The additional content below may help you determine where to deviate from the plan above.
“Save your creativity for your product… not the branch plan.” – anonymous Below are three branch plans that represent Basic, Standard and Advanced software development projects. The elements of these plans are additive so starting with the Basic plan will allow you to transition to the Standard plan if your product becomes more complex. The most common reason for adding complexity to a branch plan are additional release vehicles (i.e. Service Packs and Hotfixes). Additional release vehicles will require a branch plan that supports concurrent development for each of these. Minimizing the number of release vehicles is the key to keeping your branch plan simple. The goal of the Basic, Standard and Advanced branch plans presented below is to cover most customer branching scenarios. Please post your scenarios not covered below to the community section associated with this document at http://codeplex.com/TFSBranchingGuideII. Our hope is to leverage the Codeplex community to cover alternative (but still valid) branch cases.
Basic Branch Plan
Below is a basic plan that enables concurrent development for your next release, a stable main branch for testing and a release branch for any ship blocking bug fixes. Multiple development areas are supported by creating additional development branches from main.
These are peers to each other and children of main. Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of main and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of main).Once the release branch is created main and the development branches can start taking changes approved for the next product release.
The Basic branch plan will work well for your organization if you meet some of the following criteria:
1. You have a single major release that is shipped (i.e. a single release vehicle) to customers.
2. Your servicing model is to have customers upgrade to the next major release.
3. Any fixes shipped from the release branch will include all previous fixes from that branch.
Key elements of this plan include
1. DEVELOPMENT (dev) branches for next version work.
a. Focus on wide, flat branches to enable steady code flow to MAIN and then back to peer DEVELOPMENT branches
b. Work in DEVELOPMENT branches can be segregated by feature, organization, or temporary collaboration.
c. Each DEVELOPMENT branch should be a full branch of MAIN.
d. DEVELOPMENT branches should build and run Build Verification Tests (BVT’s) the same way as MAIN.
e. Forward Integrate (FI) with each successful build of MAIN
f. Reverse Integrate (RI) based on some objective team criteria (e.g. internal quality gates, end of sprint, etc.).
2. RELEASE branch where you ship your major release from.
a. RELEASE is a child branch of MAIN.
b. Your major product releases from the RELEASE branch and then RELEASE branch access permissions are set to read only.
c. Changes from the RELEASE branch RI to main. This merge is one way. Once the release branch is created MAIN may be taking changes for next version work not approved for the release branch
d. Duplicate RELEASE branch plan for subsequent major releases.
3. Changes should be checked into one branch only
a. All branches have a merge path back to MAIN.
b. No need for baseless merges.
Standard Branch Plan
As you add additional release vehicles you may need to create additional branches in the production/release area to enable concurrent development. The Standard branch plan below introduces a new release branch to support an additional release vehicle. Most organ
izations will call this a servicing branch to enable development of Hotfixes and Service packs.This plan will work well for your organization if you meet some of following criteria:
1. You have multiple ship vehicles (e.g. major release and additional service packs for that release).
2. You want to enable concurrent development of service pack and next version products.
3. You have any compliance requirements that require you to have an accurate snapshot of your sources at release time.
All of the guidance any key points from the Basic plan applies to the Standard plan. The Standard plan has these additional items to consider.
RELEASE branches for release safekeeping and Service Pack work
1. RELEASE tree (i.e. SP and RELEASE) are branched from MAIN at the same time to create MAIN->SP->RELEASE parent/child relationship.
2. Product releases from the RELEASE branch and then that branch is changed to read only.
3. Servicing changes are checked into the Service Pack (SP) branch.
4. Changes SP branches merge one-way to MAIN (SP->MAIN).
5. Ship stopping bug fixes checked into the release branch should merge back to MAIN through the SP branch (RELEASE->SP->MAIN).
6. Duplicate RELEASE tree plan for subsequent major releases.
Advanced Branch Plan
The Advanced plan is for products have must support many release vehicles and servicing scenarios. The plan allows for concurrent development of a major release, service packs, Hotfixes and next version work.
All of the guidance any key points from the Basic and Standard plans applies to the Advanced plan. The Advanced plan has these additional items to consider.
1. RELEASE branches for release s
afekeeping, HOTFIX and Service Pack worka. RELEASE tree (i.e. SP, HOTFIX, and RELEASE) are branched from MAIN at the same time to create MAIN->SP->HOTFIX->RELEASE parent/child relationship.
b. Product releases from the RELEASE branch and then that branch is changed to read only.
c. Check-in based on which release the change applies to (e.g. Hotfixes are checked into the HOTFIX branch).
d. Changes in HOTFIX and SP branches merge one-way through intermediate branches to MAIN (HOTFIX->SP->MAIN).
e. Duplicate RELEASE branch plan for subsequent major releases.
The plans above covers the majority of software development activities. Using these plans as a base will enable your teams to spend more time on developing high quality code and assures that each branch has a specific role. The additional content below may help you determine where to deviate from the plan above.
|
|
0 comments
Post a Comment