I have a Team Project in TFS where tasks are submitted daily. I would like to work on each task independently and then merge it into the main line after testing.
Currently there is a MAIN branch and a DEV branch which is a child of MAIN. Changes are worked on in the DEV branch and then merged into MAIN when they are ready. This is done via a "cherry-pick" merge. I've been reading everywhere that cherry-pick merges are bad and you should avoid them whenever possible.
I am having trouble wrapping my head around branching and merging in TFS and was wondering if anyone had any suggestions on how to achieve this goal in TFS without having to do cherry pick merges.
Any help is appreciated.
If I left out any key information please leave a comment and I will edit my post.
I think this Codeplex documentation will be a big help:
http://tfsbranchingguideiii.codeplex.com/
The download has several PDFs that outline different scenarios and strategies and give excellent Q&A on different approaches.
The key for your scenario would be to merge all changes up to a specified version from Dev to Main. Run all tests each time code is checked into Dev (and developers get the latest Dev code, then run all tests before checking in). Ideally, if the build in the Dev branch is successful after Dev checkin, merging into Main would be a good idea. Merge frequently from Dev to Main, and run all the tests in Main after each checkin.
So even though developers work individually on specific pieces, once they check into the Dev branch they are essentially saying "this code is ready to integrate." And when merging from Dev to Main, you no longer deal with specific pieces--you merge the whole enchilada. If Developers need source control for work-in-process code, they should use TFS shelvesets and wait to check into Dev until they are "done."
You might find Timpani Software's MergeMagician tool interesting. It is a branch management and automated merging solution that works with TFS (and also Subversion). You create publish/subscribe relationships between branches, and then the server automates the merges.
MM can be used to implement all of that patterns discussed in the TFS Branching Guide that Shawn mentioned.
FYI, it is a commercial tool. I don't know of any open source tools that do anything like this that work with TFS.
Check it out at http://www.timpanisoftware.com. There's a good overview video on the home page.
Related
I am setting up DevOps process with TFS and wondering about branching strategy. If I have the following sample branching (image from Guidance: A Branching strategy for Scrum Teams).
I have DevOps process set up (continuous integration and continuous delivery) with continuous integration from MAIN branch (with Jenkins).
How would I handle hotfixes? If developers merge frequently into MAIN branch to verify builds, how do I get the last released code for applying a hot fix? If I were to use Release branches, I would eventually have to integrate hot fix into MAIN branch in order to kick off CI process. However, MAIN branch could contain changes beyond the release.
Please advise on this issue.
Generally a hot fix should gets out from the relevant version on the main branch.
Then need to create a dedicated branch for the hot fix, merge it with the last stable branch.
If it passes the entire QA, unit tests, system tests, etc then merge it back to main branch as the next released version.
you can have a look in the following example when using git the reference is here: git best practice. The source control is not the issue but the main idea. Read carefully the article i believe you'll be able to find what you are looking for.
There are some organization that still working with patches...
I'm not a big fun of this solution, but if this is your case than let me know, because in patches there is a little bit different solution.
It's suggested making all your branches synchronized all the time. When you want to handle hotfixes, you can create a new branch "HotFix" from main. When the hotfixes are completed, you need to merge it from HotFix to Main, and merge from Main to Release.
If you have made any changes in the Release you will need to merge back up to Main in order to finalise the changes.
A hotfix is a patch to released software. If you've got a release branch, creating a hotfix branch off of that is appropriate. After that hotfix is promoted up to Prod, you can then reverse integrate back up the chain to Main. Hotfix -> Release -> Main, and even forward integrate that up to the next sprint, if needed.
Obviously, the answer that you choose depends on your particular requirements; however, typically, you should cut a release from main, and a hot fix from the release branch. Personally, I would say that that code should not go back into the release branch, but be double fixed in a development branch.
The main reason for this is that, once you've released code, that code branch should be locked as it was at release. If you follow this, then you can always go back to a previous state of affairs. As has already been suggested, you may be halfway through changes to a hotfix when the requirement or priorities change; or when the customer reports a bug in the live code. If you maintain a separate branch, you can always access that code.
How to handle this really depends on the release and maintenance strategy or customer agreements you have.
If your release branch happens also to be a maintenance codeline (it seems like it from your description) then create feature branch from it, implement a hot-fix, test, merge back and release a "patch". Ideally you should have CI set also for the "maintenance" branch.
After this you can integrate your hot-fix with main codeline or put the issue on backlog to implement it differently for the future new release.
BTW: Some nice articles here:
https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging
and
http://www.bradapp.com/acme/branching/branch-creation.html
If you are using Agile, then feature branches can be a good option. The only thing is it has to be combined with a ticketing tool like JIRA or AGM. For handling hotfixes in such scenarios, you can have a user story in AGM or JIRA, which upon completion will be merged onto the mainline trunk.
Currently we have a branch structure like this: Develop --> Release. I want to change it so that it looks like what the TFS Branching Guidance document calls "Basic Branch Plan". It looks like this Develop <-- Main --> Release.
I was going to do this:
Rename Develop to Main (creating Main --> Release)
Creating a branch from this Main reusing the "Develop" name (creating Develop <-- Main --> Release)
Will I have problems with TFS reusing an old branch name for a new branch? Know any gotchas or things to look out for?
Additional Info
I did this in a test instance creating test branches without any files, pending changes, history, etc. (not a good real test) and TFS let me do the rename and branch without difficulty. However, I won't feel comfortable with this unless I can take our production TFS project collection, restore it in the test instance, and test the rename/branch on real data. There is a lot of history and branches there and I don't know what will happen. As noted in the answer, there are other considerations before doing this.
I'm preparing to do similar steps (except I'm moving subfolder locations of both parent and a child while grandchildren stay put.)
QUESTIONS:
When are you planning the rename?
Are there any child branches under Develop branch that you didn't mention?
Do you have any shelvesets against Develop that might be impacted by the rename?
General answer: Proceed with caution. From my reading branch renaming in TFS2010 can cause a few unexpected side effects. TFS will be doing the following steps (under the hood) for your scenario:
Rename Develop to Main ==> Branch Main branch from Develop, then delete Develop branch
Create new "Develop" branch from Main
I recommend reading the following posts:
Renaming Branches in TFS 2010 (ChandruR’s Blog)
"MSDN Blogs > ChandruR's Blog > Renaming branches in TFS 2010
So my recommendations for this case:
Avoid renaming branches - a cleaner solution would be to, at the right point in your release merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
Or for the brave of heart :)
You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are:
..."
Renaming branches in TFS2010 - But it works on my PC!
“In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted items in source control explorer’ enabled…”
"Now implemented as a branch + delete behind the scenes (new name is branched from the old, then the old name is deleted). This allows traceability in History, but allows us to get around the problems with merging renames (see Add, Rename, Add scenario). "
.
RANDOM THOUGHTS
Get all devs to merge (or abandon) all safe changes in child branches of Dev. Also prune any inactive branches before the rename.
Read above articles.
Search to find the page (that I haven't found yet) that describes exactly what will happen in simpler terms based on real experience.
Specifically I'd like to know what happens to shelvesets on the Develop branch after it is renamed to Main. (Next step can answer this.)
You might consider making a "Sandbox" Team Project (or Team Project Collection) then try out your scenario to see if there are major issues.
Pick right timing (see link#1) and go for it.
Check history, do a merge between the renamed branches, check history again.
Allow developers back in.
Good luck, and post back with any new information (including your end results)! -zs
While I am rebasing our branch, rest of the team continues working on code. Rebase lasts about 1-2 hours. I'm doing it from merge in context menu when you right click the folder to merge, so nothing special here.
Team members check-out code, alter it but they do not check in. What risks this approach has? What is the best practice for this situation? How your team handles such cases?
I think what you're suggesting is a fairly standard approach and just to make sure I understand the question, here is a scenario.
There is a Main branch. From this Main branch 2 development branches have been created (devA and devB) these branches will be used to make changes to the code for 2 seperate projects.
The development in devA has reached a stable state and has been merged in to the Main branch. Now you want to merge the changes from Main in to devB
In devB the developers have been coding changes and have a number of files checked out. You don't want to make the developers check in their changes to devB and you don't want to initiate a code freeze whilst the rebasing takes place.
If the developers have been checking in changes to devB on a regular basis since the branch was created, you will porbably see merge conflicts when you try to merge the devA changes from the Main branch. Someone familiar with the code and requirements for both "projects" will need to help resolve those merge conflicts. Once the conflicts have been resolved you'll probably want to check that the code compiles and that any unit tests run and pass. If you have compilation errors or unit tests fail then this will need investigating.
Once you're happy that the merge from Main to devB has been sucessful then the developers with files checked out in devB can start to check in changes. If the files they have checked out were not changed as part of the merge from Main then the files will check in as normal. If however they have files checked out that were updated as part of the merge, TFS will bring up the merge conflict resolution tool and the developers will need to resolve any conflicts before they can check in the code.
Hopefully the above is resaonably close to the process you're currently following? If I've missed anything, or missed the point entirely then let me know.
This isn't as nice as it could be, but it's a common approach and one that we use.
The risk to this approach is that you could end up spending a lot of time fixing merge conflicts, especially if you have a large codebase with a lot of developers changing the code in a lot of branches.
To mitigate any problems, it's best to rebase as early and as often as possible. Early because if you save everything up till the end of devA's project, then the changes could have a significant impact on devB. Often because the number of conflicts per merge is minimised, making conflict resolution simpler and less error prone.
Setting up a "continuous integration" build will also help as you'll see compilation problems sooner rather than later. If you're using TFS 2010 then Gated Checking may also be helpful.
I'm not 100% sure that this answers your question so let me know if I've missed anything
There are several/many questions regarding TFS branching strategy, but I am haven't been able to come up with a strategy that fits with my scenario. My TFS project consists of a single solution that contains a Web Project, a Business Layer Project, and a Data Layer Project. The project is a portal of reports. Reports are largely isolated in subfolders within the project. There are however some features across the entire project such as session management. Over a given period of time, the workflow may occur as follows:
Stable snapshot of code.
Development of Report A begins.
Development of Report B begins.
The project with the inclusion of Report A needs to be pushed to our qa environment.
The project with the inclusion of Report A and Report B needs to be pushed to our qa environment.
The project with only the inclusion of Report B needs to be pushed to our prod environment.
So basically, each report is on a completely independent timetable. I need to be able to independently publish a branch of code to our different environments. Currently, we don't have branching - we just don't add a link to a new feature if the project gets published when a report isn't ready but is included in the project. Not the best scenario.
My initial go at a branching strategy was to have Main sit between the QA and prod environments, basically as just a container to merge before branching to a production branch for a production publish. Each report would be developed on a branch from main. For both our test and qa environments, a branch from main would be created and the appropriate development branch(es) would be merged into this "proposed updates" branch. This doesn't work though because I am merging development/feature branches into a branch that isn't the parent branch. I can't have Main at this level because a Report may be in development for weeks while another may be on a timetable that has it developed and pushed through the process to production in only a few days. My "proposed update" branches for test and qa need to be able to be independently created from a merging of only the appropriate dev branch(es).
My only experience with branching/merging is a main+dev pair of branches, so I'm very out of my element here. How can I setup my branching in such a way that I am able to merge features in on independent timetables without getting stuck and code being published to an environment before it is ready?
If it matters, we are on TFS 2008 right now and hope to go to TFS 2010 soon. This is an immediate need to get going on our current TFS 2008 server though.
I'm not exactly clear on everything; reading comprehension and all.
As I understand it, your current process is Dev -> Test -> QA -> Production. Devs work on code, push it to an environment where they can test on it. Once satisfied, they push it to QA, and when code passes it moves into production.
In addition, you have several "teams" (1 or more devs) that must work on separate reports, each of which must eventually be moved through the above process into Production. Teams may be working on code that is distinct from all others, or teams may find they cannot move their code forward until other teams reach stability.
If I were in charge of branching for this solution, I would recommend the following.
First, create a Production branch. This branch only contains production code. Only your QA team touches this branch.
Next, create a QA branch. This branch is also maintained solely by QA teams. They manually merge test code into this branch, run their quality assurance tests, then merge with Production. Every time they merge with Production, or test code is accepted into QA, a label is applied to the branch. If test code fails, the branch is reverted back to the prior label.
Development teams manage their own branches. They are created by branching from QA at the latest label. This assures they are working with the latest approved code. Developers work with and test on this branch. If teams have a dependency on each other, they should work on the same branch, unless it becomes clear that creating secondary branches from their shared Dev branch would be easier. Once a Dev branch meets the milestones set for the developers, QA should be informed that the branch is ready for merging with QA for testing.
Alternatively, depending on how complex development is, you might even consider uniting the QA and Production branches. Often, it is a simple matter to add a label to a branch to indicate a stable, production worthy build. It also keeps the branching strategy as simple as possible, which is always a good thing.
I think you should look at the Branching Guidance put together by the VS ALM Rangers.
http://tfsbranchingguideiii.codeplex.com/
This should alswer all of your questions. You are looking at quite an advanced branch plan. I also have some good practical guidance on my blog. I know that I am talking about Scrum teams, but it is basicaly Feature branching based on the Guidance.
http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx
If you get a chance please vote over
at the new "Visual Studio ALM"
StackExchange over in Area51 as we are
trying to setup a place dedicated to
answering these questions with the
Visual Studio ALM MVP's and Visual
Studio ALM Rangers on hand to answer
your questions.
http://area51.stackexchange.com/proposals/15894/visual-studio-alm
[I know this question is old but this may help others that come across this question]
Most "branch per feature" teams use one "main" branch and break away from the branch per environment approach. Environment releases can be handled by clearly labeling each environmental release on the MAIN branch.
The QA release is the result of merging all features/issue branches considered fully tested and ready for QA into MAIN. As bugs are found, new bug branches are branched off of MAIN, which are fixed and merged back to MAIN. When all QA releases are deemed ready for production, a PROD build is made from MAIN. In short MAIN is the one source of truth for code.
If you need to work ahead, an integration-test branch (TEST) can be used to determine what features are "production ready," but feature/issue branches should be merged to MAIN on a case-by-case basis, rather than in bulk from the TEST branch.
Hotfixes can be branched from the PROD label, then fixed, tested and merged back to MAIN for a new PROD release.
I'm going to refer you to a great video on Branch per Feature. It focuses on GIT, but the strategies do not depend on GIT and can be used just as effectively on TFS SCC: https://youtu.be/9SZ7kSQ2424
I am working with a small development shop that consists of a group of 5 developers and 1 QA person. We are using TFS and need to get more sophisticated on how we use this tool.
Currently the development team checks in their code each evening. A nightly build runs and pushes the output out on a network share. Our QA person uses this build for testing the next day. Sometimes the build off the trunk codebase has issues/bugs that hinder the QA process, and it hasn’t been a giant issue in the past, but we now want to get to a state where we have our QA person testing on a stable QA build.
So I believe we need to create a branch (call it QA), and the developers will continue to develop off the trunk, but the QA person will use builds created from code in the QA branch.
Seems simple enough, but we have started doing code reviews as well. So we have another desire in that only code that has been code reviewed can be promoted to the QA branch. Each developer works off a TFS item, and when they check in a changeset, they do it against a TFS item which creates a link between a checked in code file and a TFS item. Eventually the TFS item becomes complete and ready for code review. All code attached to the TFS item is reviewed. How can the versions of these files get promoted to the QA branch?
In the QA branch, if a bug is found, we want to fix it in the QA branch and have the changes migrated back to the trunk. I believe TFS has a way to automatically do this doesn’t it?
Long story short, we want to get to a build and CM environment that I believe is pretty standard, but we are unaware of how to make this happen with TFS. Given our situation above, can someone point out a book or website(s) that would address our specific needs? We would like to make this happen without having to get too deep in CM theory or TFS.
I very much appreciate any and all suggestions!
Thanks,
John
You might want to take a gander at the resources on CodePlex. There are different strategies laid out for how you might want to build your branching model.