This project has moved. For the latest updates, please go here.

Branching Setup Help Please

Oct 4, 2010 at 1:45 PM

I have always worked in 1-2 developer shop and never used branching, (aka simple check in and check out).  (Mostly due to zero guidance) and now I have to setup branching because, so much work is being thrown our way.   Here is the situation.

Using TFS 2008

Due to restrainsts we have been given (1) Project where we support our portfolio of applications usins AREAs under the Parent PROJECT

 - Top Level = Portfolio

     -Project 1 (Folder)    (Here is my questions after following the guides)

           Inside of Project 1 do I want to create 3 folders?

            - DEV_Description_To_Define_What_This_Dev_Is_For

            - MAIN 

            - RELEASE_Description_To_Define_What_This_Dev_Is_For_To_Match_Dev_Above

Contintue to follow this for all projects

    - Project 2    

 

1) When I set this up do I just add the files from my local system into MAIN then BRANCH to DEV and Release?   Or do I add files to DEV and Branch to MAIN and Release.  Again this is my first time doing this.

2) Do I lock down MAIN to where only certain folks can merge from DEV to MAIN and the same for MAIN to Release...

3) Once the DEV for a certain fix is complete do you delete the branch and create a new branch for future enhancements and bug fixes so you do not step on others

 

 

Developer
Oct 4, 2010 at 2:43 PM
  1. Create your Team Project ($/Porfolio)
  2. Create a Main folder (checkin all changes)
  3. I typically add a folder (under Main) called Src - this is where I recommend you add your local system.
  4. Check-in all changes.
  5. Next Branch Main to Dev (Do Not branch Dev to Main)
  6. Depending on the state of your code (is it ready to release? or is it beginning a new Dev cycle?).. branch Main to Release when you have tested the code in Main and are ready to release.

You might have certain people (for example Dev Leads or Project Managers) who are allowed to do branching and merging. Certainly it might be advisable to lock down main to prevent all developers from doing branching or merging.

Typically, Dev used for future releases and the Release branches are used for Hot fixes and / or Service Packs. Once you finish a Dev cycle, and release the code you would at this time create your release branch structure (branch Main to Release). This frees up the Dev branch for future enhancements (thus isolating them from the fixes being made to released code). It is not necessary to delete the Dev branch.. simply begin development of the next release, but only merge Dev to Main when it passes quality gates.

Make your hot fixes in the servicing (release) branches. If desired, you can merge these fixes up to Main (and then up to Dev). But once you create a release branch, you should not merge from Main to Release (since Main and its Dev branches are now focused on future enhancements).

Regards,
Bill Heys
VS ALM Ranger

 

Oct 4, 2010 at 4:23 PM
Edited Oct 4, 2010 at 4:25 PM

Bill,

Thanks for the quick reply.  I have a couple of questions from the following:

  • Create your Team Project ($/Porfolio) ---- Done IE  MyPortfolio
  • Create a Main folder (checkin all changes)   ----  Is it ok to have then insid MyPortfolio seperate projects

    $/RTI  (BILL due to TFS standards they will only give us 1 Project and we have to maintain all our apps in that project per group to keep cost down and limitations of number of projects on TFS server...  Note: I do not work on the TFS team, just a Tech Lead to where I want to get the most out of TFS to support developers)

    $/RTI/App1

    $/RTI/App1/DEV_Change_GridView_Enhancement_Project   (Note this was Branched from MAIN below
    $/RTI/App1/MAIN
    $/RTI/App1/Release__Change_GridView_Enhancement_Project   (Note this keeps releases seperated  --- Correct or am I misunderstanding?)


    THEN REPEAT FOR ALL OTHER APPS IN THE $/RTI Portfolio, because you can define work scope by AREAS?
    $/RTI/App2

    $/RTI/App2/DEV_Change_GridView_Enhancement_Project   (Note this was Branched from MAIN below
    $/RTI/App2/MAIN
    $/RTI/App2/Release__Change_GridView_Enhancement_Project   (Note this keeps releases seperated  --- Correct or am I misunderstanding?)

     

  • I typically add a folder (under Main) called Src - this is where I recommend you add your local system.   (I do not understand the purpose of this because isn't MAIN the SRC?
  • Check-in all changes.
  • Next Branch Main to Dev (Do Not branch Dev to Main)   (Again this is my first time do I need to setup the DEV folder or will the Branch do this?)
  • Depending on the state of your code (is it ready to release? (YES it is stable and ready to setup this process of work) or is it beginning a new Dev cycle?  --- I will be beginning a new Dev Cycle once the Branches are correct).. branch Main to Release when you have tested the code in Main and are ready to release.

     

  • Developer
    Oct 4, 2010 at 4:36 PM

    1. I generally have separate team projects for each application. I tend to prefer this over having many *Main, Dev, and Release* branches within a single team project. I prefer this when App1 and App2 are on separate dev and release cycles. On the other hand if you are enhancing both App1 and App2 as part of a single dev and release cycle (a single initiative or single enhancement project), then your branching structure makes sense. You can more easily manage a project since work items cannot cross Team Project boundaries. 

    2. I would recommend keeping all folder names as short as possible. If not you are likely to run into path length (max 260 characters) problems

    3. In addition to source, I may have other things under the Main branch. For example I might have a docs or bin folder for files I want checked into source control (and branched with my source)

    4. When branching Main to Dev, you do not need to setup Dev first, Dev will be created by the branching operation

    5. I would recommend, given your answer to the last question, making sure that your code in Main is stable and ready to release (you say you have done this). Next branch Main to Release (or a set of Release branches - see the basic, standard, advanced branching plan). Finally branch Main to Dev to being the next cycle. (note - there probably is no difference whether you create the dev branch after the release branch or the release branch after the dev branch. Key is to have Main stable, and have Main be the parent of both the Dev and Release branch.

    7. You are correct that having a Release branch keeps releases separate (from the Main branch - where new development is being supported)

     

     

     

    Oct 4, 2010 at 8:51 PM
    Edited Oct 4, 2010 at 8:52 PM

    I would add in 3 things:

    1) If you want to use the Branch Visualization feature in TFS 2010 don't create the scr folder under main, instead directly branch from the Main folder to the Development folder (which is created by the branch operation).

    2) After creating and checking the Main folder into TFS 2010 you need to right click and choose convert to branch under the branching and merging menu so that the branch visualization and track changeset features will work when you branch.

    3) I strongly recommend against having seperate team project for each application. Inside of Microsoft, both the Developer Division and the Office division each have 1 team project for their entire portfolio. [Think the Visual Studio and .Net Framework teams live under 1 team project, the Word, Excel, and PowerPoint teams live under 1 Team Project (Office for example).

    Oct 4, 2010 at 9:36 PM

    Here is what I did...

    Created the application folder called

    ABC

       Next I created ABC/MAIN

    Opend the ABC.SLN --- compiled and the application is running as designed.

    Next I BRANCHED from MAIN to ABC/DEV   Worked like a charm.

    Repeated the process for ABC/HOTFIX  and ABC/RELEASE.

     

    I then did some minor changes to DEV and Merged with MAIN worked as designed.  

     

    Now on to the next topic  LABELS   When do you use them and what is the benefit?  

    Oct 4, 2010 at 10:16 PM

    OK... I do have a question about the MERGE now...

    I checked out on the DEV branch...   Added a simple comment.   When I do this the BRANCH symbol goes away (45 Degree Arrows).   Is it then a manual job to ensure that you merge changes aka Merge from the Folder Level or File Level back to the MAIN.

    Next I go to the MAIN Branch and see the Vertical Arrows one pointing down the other pointing up.   I am assuming it is then the MAIN branch admin's job to "Check In Pending Changes" to complete the merge.  Is this correct? 

    Note: I am doing this as I write this.   So, I will test one and see if the BRANCH symbol reappears in DEV branck... brb

    Ok, I cso not I checked in pending changes and the Vertical Arrows are gone, but now there is is not a BRANCH symbol next to the DEV File and longer.    Do I have to rebranch from MAIN?    Sorry for all the questions.  I am just really new to this and want to be sure I understand.

    I event tried to Branch the file again and get The item "aka file" already exists...  So how do you get files from possibly another Deveopment Branch that got merged from MAIN back to DEV?

     

     

     

     

     

    Developer
    Oct 5, 2010 at 1:10 PM
    Edited Oct 5, 2010 at 1:11 PM

    My response to Allen's points:

    1. Creating one or more folders (for example Src, Dev, or Bin) under the Main branch in TFS 2010 doe not prevent branch visualization. To be clear, I am not changing the source of the branch operation (it will be Main), but there is, with my recommendation, the opportunity to have sub folders under the branch, which will be part of the Dev branch, Release branch, etc. If you don't want these sub folders, don't create them. But it has nothing to do with the visualization.

    3. Having separate team projects works well when these two projects need different process templates, are for completely separate teams (e.g. Office and Visual Studio) or are developed and / or released on different schedules. Having multiple applications within the same team project works well when these applications are developed and released together. This is why the Office Division and the Developer Division do not coexist in the same Team Project.

     Bill Heys
    VS ALM Ranger

    Developer
    Oct 5, 2010 at 1:21 PM

    Merging is always a manual process. When a developer checks out a file, makes a change, and checks-in this change - the developer controls when (or when not) to do this check-in. You should not want checked-in changes in a Dev branch to be automatically merged to the Main branch. You should alway control when and how merges are done. We recommend fully testing the changes in a Dev branch (in other words, the Dev code should pass quality gates) before it is merged into Main.

    Once a merge completes, changes are pended against the target branch. These need to be checked-in to complete merge.

    I am concerned about some of your process. I think you are using the term DEV file when in fact it is a folder (or branched folder in TFS 2008, in TFS 2010 it would be a true branch). The arrows are not a BRANCH symbol, more likely they are an indication that a file has been checked-out or has pending changes. Once you branch Main to Dev, you have a merge releationship. You can merge from Main to Dev and / or from Dev to Main.

    Please read (or re-read) the Branching Guidance and related documents. I think you will find that most of your questions are answered (or avoided) if you follow the recommended processes in the guidance.

    Regards,
    Bill Heys
    VS ALM Ranger

    Oct 5, 2010 at 7:24 PM
    See below

    wheys wrote:

    Merging is always a manual process. When a developer checks out a file, makes a change, and checks-in this change - the developer controls when (or when not) to do this check-in. You should not want checked-in changes in a Dev branch to be automatically merged to the Main branch. You should alway control when and how merges are done. We recommend fully testing the changes in a Dev branch (in other words, the Dev code should pass quality gates) before it is merged into Main.

    Once a merge completes, changes are pended against the target branch. These need to be checked-in to complete merge.

    I am concerned about some of your process. I think you are using the term DEV file (I am referring to DEV folder not file) when in fact it is a folder (or branched folder in TFS 2008, in TFS 2010 it would be a true branch). The arrows are not a BRANCH symbol, more likely they are an indication that a file has been checked-out or has pending changes. (I am unsure on this because when I perform the branch the arrows are pointing to the Right and down 45 Degrees to the right as well) Once you branch Main to Dev, you have a merge releationship. You can merge from Main to Dev and / or from Dev to Main.  (I agree with this)

    Please read (or re-read)  the Branching Guidance and related documents. I think you will find that most of your questions are answered (or avoided) if you follow the recommended processes in the guidance.

    Regards,
    Bill Heys
    VS ALM Ranger

    Bill thanks again for all the assistance...

     

    Oct 5, 2010 at 8:01 PM

    Bill so here is the new scenario:

    Developer A is working from the DEVELOPMENT BRANCH they make a change on one file,  do you think of merging rather at a FOLDER level or can you do it from a FILE level.   Because the problem I see is if DEVELOPER B was working on another BRANCH and merged to MAIN then how can you get MAIN back to Developer A.   I tried to branch the single file again and get the error message: "The item $RTI/AppCode/DEV/Web.config already exists."

     

     

     

     

    Developer
    Oct 19, 2010 at 11:00 PM

    Merging is only done at the branch level. If you branch MAIN to DEVELOPMENT, your only choice is to merge DEVELOPMENT to MAIN (or MAIN to DEVELOPMENT). The problem you pose is a classic challenge where two developers (or development teams) are working on separate development branches of MAIN. When Team A finishes their work in a their Dev branch and it is tested and passes some predetermined quality gates, the code from Team A's branch can be merged (integrated) into the Main branch. Before you do this, however, make sure that you do a final merge (forward integration from Main into Team A's Dev branch and test this integration first in their dev branch. Once the integration of the Team A's Dev feature is tested, merge Team A's Dev branch to Main and do a final round of integration testing. At this point, Main has the code from the Team A. The next time you merge Main with Team B's Dev branch, you will bring the Team A's code to Team B. The integration of this should be tested in Team B's Dev branch before being merged back down to Main.

    Regards,
    Bill Heys
    VS ALM Ranger

    Oct 20, 2010 at 1:09 PM

    Wheys,

    I am proud to report that with my current branch and merge model based on the TFS Rangers I have been successful and now developing as a full blown software shop.

     

    $PortfolioNameofAppsSupported - tfs.domain.com

     - App1 (Simply Folder to hold the other folders

    --Main this is where the Original code goes

    --------Branch DEV FROM MAIN

    --------Branch HotFix FROM MAIN

    --------Branch Release FROM MAIN

    And I have been merging back into MAIN then merging out to the other BRANCHES to ensure all is in sync.  Works like a charm....

     

    Developer
    Oct 20, 2010 at 2:52 PM

    Thanks for the feedback. I am glad things are working well. My only suggestion would be that you should branch Hotifx from Main (as you have done) and then Release is branched from Hotfix.

    Regards,

    Bill Heys
    VS ALM Ranger

    Developer
    Oct 20, 2010 at 3:00 PM

    With respect to the Hotfix and Release branches, our guidance recommends waiting until you test the code in Main before creating these branches. Once you create the Hotfix and Release branches, development can continue in the development and main branches for the following release. You do not want to merge from Main into the Hotfix / Release branches once you create them. Doing so would bring vNext code into your vCurrent release.

    Oct 20, 2010 at 3:33 PM

    It reads to me a bit odd that you note your branching as based on TFS Rangers while is nothing of what they recommend.

    - App1 (Simply Folder to hold the other folders

    --Main this is where the Original code goes

    --------Branch DEV FROM MAIN

    --------Branch HotFix FROM MAIN

    --------Branch Release FROM MAIN

    The release branching tree is clear in the document and what purpose it serves.

    But do not feel bad, I was only partially able to get my team to understand it.

    They end up opting for implementing the visually similar branch but insisted into checking FI code from SP into HF into RTM for SP releases.

    It was impossible to convey the idea that HF, SP, and RTM are all release branches.

    From: moojjoo [mailto:notifications@codeplex.com]
    Sent: Wednesday, October 20, 2010 6:10 AM
    To: Ramon Aldana Borjes
    Subject: Re: Branching Setup Help Please [TFSBranchingGuideIII:229540]

    From: moojjoo

    Wheys,

    I am proud to report that with my current branch and merge model based on the TFS Rangers I have been successful and now developing as a full blown software shop.

    $PortfolioNameofAppsSupported - tfs.domain.com

    - App1 (Simply Folder to hold the other folders

    --Main this is where the Original code goes

    --------Branch DEV FROM MAIN

    --------Branch HotFix FROM MAIN

    --------Branch Release FROM MAIN

    And I have been merging back into MAIN then merging out to the other BRANCHES to ensure all is in sync. Works like a charm....

    Read the full discussion online.

    To add a post to this discussion, reply to this email (TFSBranchingGuideIII@discussions.codeplex.com)

    To start a new discussion for this project, email TFSBranchingGuideIII@discussions.codeplex.com

    You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

    Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

    Oct 20, 2010 at 5:05 PM

    wheys and edaurdo that is what I am doing.

    If a bug is found we work in HOTFIX while continous Development happens.   Once the HOTFIX is done the HOTFIX Branch is Merged to MAIN then MAIN Merged to Release and deployment from Release.   Finally the code from MAIN is merged to DEV to ensure the fix is put into the DEV Branch...

    Dev is not merged with MAIN until all requirements for the new DEV is completed.

    Developer
    Oct 20, 2010 at 5:26 PM

    Once again, we do not merge Main to Release after the Release branch has been created. To summarize:

    1. Create the Main branch.
    2. Branch Main to Dev and begin Development of V1.0 code in the Dev branch
    3. Once the code in the Dev branch passes predetermined quality gates, it is ready to be merged to Main. Do a merge (Reverse Integration) from Dev to Main
    3. Stabilize the code in Main (Deploy to QA for testing)
    4. Once the code in Main passes the predetermined quality gates it is ready for release.
    5. Branch the Main branch to Hotfix 1.0
    6. Branch Hotfix 1.0 to Release 1.0 and make Release 1.0 Read-only.
    7. After releasing Release 1.0, the Main Branch and the Dev Branch(es) are now available for V2.0 development - this is why you would not merge Main into a release branch once it is created. You would be overlaying released code with new feature development.
    8. If post-release bugs in Release 1.0 are discovered, fix them in the Hotfix branch - and ship the hotfix (possibly as a patch) from the Hotfix 1.0 branch.
    9. Merge the Hotfix from Hotfix 1.0 to Main (Reverse Integration) - this allows the hotfix to be part of the next (v2.0) release
    10. Meanwhile V2.0 development is taking place in Main and the Dev branches
    11. The Release 1.0 branch contains the state of the code as it was released (some organizations have an audit requirement here). It is read only and Hotfixes are NOT merged into this branch.
    12. The Hotfix 1.0 branch contains fixes made after Release 1.0 was shipped. Each hotfix can be labelled and shipped as a patch rather than as a full release.
    13. When development on V2.0 is complete, it is tested and once it passes quality gates it can be merged to Main (same as step 3).
    14. On a daily basis, while development proceeds on vNext (v2.0), do a nightly build of the Main branch. Any changes in Main (such as hotfixes that have been merged into Main) need to be fully tested by QA
    15. When you get a good daily build in Main, merge Main to the Dev branches (Forward Integration), but NOT to the Release branches.

    Code merges from Main to the Dev branches on a daily basis following a good Main build (hopefully with Build Verification Tests)
    Code merges from Dev to Main when they are feature complete and they pass quality gates (typically feature complete is a milestone)
    Code never merges from Main to Release branches - this will overlay released code with future development that might not be completely stabilized.
    When released, code is branched (not merged) from Main to the Release branch(es). The Service Pack, Hotfix, and Release branches are all created at the same time. If you are using the advanced plan, Main is the parent to Service Pack, SP is the parent to Hotfix, and Hotfix is the parent to Release (which is read only)

     

    Regards,
    Bill Heys
    VS ALM Ranger

    Oct 20, 2010 at 6:56 PM

    Bill this makes 100% sense.   However now I have one other final question.

    For each new release do you create a new Release Branch?

    Release1

    Release2

    etc.

    Or do labels come into play here?

     

    Thank you so much for all the input this a very valuable thread.

    Developer
    Oct 20, 2010 at 7:20 PM

    Just to make sure we are using the same terminology here, let's frame this response in the context of a Microsoft product such as Windows.

    Over the last few decades, Microsoft has released many versions of Windows for the desktop. I can remember many *major* releases. For example:

    • Windows 1
    • Windows 2
    • Windows 2.1
    • Windows 3
    • Windows 3.1
    • Windows 95
    • Windows 98
    • Windows ME
    • Windows XP
    • Windows Vista
    • Windows 7

    For each of these *major* releases we would have a separate release branch.

    For each of these releases, we my have many if not dozens or hundreds of hotfixes. We might also have a few services packs. For example, I believe Windows XP is now on Service Pack 3 while Visa is on Service Pack 2.

    A hotfix is typically made to fix a specific bug for a specific customer (or limited set of customers). We often call this Quick Fix Engineering (QFEs). While hotfixes need to be tested, they are not subjected to the rigorous, time-consuming, exhuastive testing that a major release or even a service pack must undergo. For this reason, we often advise customers to only install a specific hotfix if they are experiencing a problem that the hotfix is designed to solve.

    For hotfixes, I would generally recommend simply doing a label, in the hotfix branch, of each hotfix. The hotfix would be shipped as a patch rather than a full install. But for major releases (for example Windows 3.0) and even minor releases (for example Windows 3.1) I recommend having a separate release branch. In some cases, such as in an agile project where releases are incremental and frequent, you might use labels instead of separate release branches. The overhead of creating a new branch is not significant. TFS stores the delta (changes), not copies of entire files. Since a release branch is made read-only, it would not have a lot of overhead, since it would not contain a lot of changes (or changesets).

    Labels, on the other hand are not immutable. This means that the content of a label can be changed over time. Files or changesets can be added or removed from a label. For this reason a label is useful for marking a milestone in a branch, but probably not as good a Release branch for keeping a copy of the code *as it was released* for archiving or audit purposes.

    Regards,
    Bill Heys
    VS ALM Ranger

     

     

    Oct 20, 2010 at 7:29 PM

    Bill,

    I had been looking for a 101 course for Branching and Merging and you have taught me well.   I thank you for your time.   I totally understand this now.  Hopefully, I will continue on .NET Development with TFS as the backbone source control, but I believe this theory would apply to any source control that a developer is involved with.

    Thank you so much,

    Robert Dannelly.