Team Foundation Server (TFS) – Branching Guidance 2010 2010-03-20 Visual Studio ALM Rangers · DEVELOPMENT branches Changes for next version work. · MAIN branch This branch is the junction branch between the development and release branches, representing a stable snapshot of the product that can be shared with QA or external teams. · SERVICE PACK (SP) A collection of hotfixes and features targeting a previous product release. · HOTFIX A change to fix a specific customer blocking bug or service disruption. · RELEASE branch A branch where ship stopping bug fixes are made before major product release. After product release this branch usually becomes read-only. · FORWARD INTEGRATE (FI) Merges from parent to child branches. · REVERSE INTEGRATE (RI) Merges from child to parent branches. · RELEASE VEHICLE How your product gets to your customer (e.g. major release, hotfixes and/or service packs). Basic Branch Plan The Standard branch plan introduces a new release branch to support an additional release vehicle. Most organizations will call this a servicing branch to enable development of Hotfixes and Service packs. · You have multiple ship vehicles (e.g. major release and additional service packs for that release). · You want to enable concurrent development of service pack and next version products. · You have any compliance requirements that require you to have an accurate snapshot of your sources at release time. The Advanced plan is for products that must support many release vehicles and servicing scenarios. The plan allows for concurrent development of a major release, service packs, hot fixes and next version work. Vocabulary BRANCHING Quick Start 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. Consider when à · You have a single major release that is shipped (i.e. a single release vehicle) to customers. · Your servicing model is to have customers upgrade to the next major release. · Any fixes shipped from the release branch will include all previous fixes from that branch. Standard Branch Plan Consider when à Advanced Branch Plan Common SCENARIOS For more information, refer to http://tfsbranchingguideiii.codeplex.com DEV FT1 MAIN Branch RI PRODUCTION V1.0.1 FI V1.1 (Release) V1.0 (hotfix) V1.1 Golden DEV FT2 DEV FT3 Branch V1.1 FT2 V1.1 FT1 V1.1 FT3 RI RI RI Branch Branch FI V1.1 FT2 (start) V1.1 FT3 (start) V1.1 FT1 (start) V1.1 FT1 VSS BM V1.0 FEATURE 1 TEAM 1 RELEASE 1 MAIN Branch FEATURE 2 TEAM 2 Branch Branch Branch RI RI RI 1 DEV MAIN Branch FI V1.1 (start) V1.1 FT3 RI V1.1 (bug fix) FI V1.1 FI V1.2 RI V1.2 V1.0 Production Single Team Branching Model Allows an organization to improve their engineering practices, by focusing on the flow of source code throughout the development process, using very simple branching model. It is imperative that the MAIN branch be stable with the latest customer-ready version Concurrent Hot Fix, Service Pack and V.Next Branching Model This scenario allows organizations to service a released product with hot fixes, with a cumulative service pack that includes all approved hot fixes, and the ability to work simultaneously on the next version of the product. Multi Feature Teams Scenario Branching Model In the Multi Feature Teams scenario, The DEV now becomes a container node which contains a group of branches where each branch is dedicated for a particular feature. The MAIN is still a single branch as alike other scenarios. When MAIN is ready to release, create the SERVICE PACK, HOT FIX, and RELEASE branches at the same time. The RTM branch is a read-only copy of what was released Team, Feature, Release Isolation Branching Model In this scenario branching is used as a policy for code promotions and each branch has an owner. The owner of the branch has to ensure that the policy is enforced (for example code reviews have been completed). This scenario is time intensive and involves quite a number of people. KEYS Branching Node Label Milestone Build FI Forward Integration RI Reverse Integration BM Baseless Merge BRANCHES Main Production Other Development Feature Release Changeset Source Structure WoodGroveBanking Dev Source Main Source $ + - + - Source Structure + - - + - + - WoodGroveBanking Dev Dev-1 Source Dev-2 Main Source Production Source Dev-3 $ + + Source Structure - - + + - - + + - - - + - + - WoodGroveBanking Dev Feature1 Source Feature2 Source Main Source Team Team1 Source Team2 Source $ Production Release1 Source Source Structure + - - + - + - + + - + - - - WoodGroveBanking Dev Dev-1 Source Dev-2 Source Main Source V1 Hotfix Source RTM Source Service Pack Source V2 $ + Branch DEV-1 DEV … MAIN R1 (SP) RTM Branch Branch Branch Branch Branch Branch Branch Branch SERVICE PACK R2 (SP) HOT FIX R1 (SP0) R1 (SP1) R1 (SP0) R1 (SP1) R2 (SP0) R2 (SP0) FI 1 2 2 3 4 5 6 7 8 DEVELOPMENT MAIN Branch RELEASE Branch Development Production / Release flow of merges (changes) flow of merges (changes) DEVELOPMENT MAIN Branch SERVICE PACK RELEASE Branch Branch Development Production / Release flow of merges (changes) flow of merges (changes) MAIN SERVICE PACK HOT FIX RELEASE Branch Branch Branch Production / Release flow of merges (changes)