I am new to TFS and trying to figure out how to get my new rewrite of an existing application into TFS properly with Branching...
I have a project where I have three branches Dev Main and Prod
I just created a new branch off the Dev called Dev-branch-Rewrite I was able to get my code into the Dev-branch-rewrite but it doesnt show the main as being a branch I can merge to. I have done something incorrectly. Not sure what I am doing wrong
TFS forces a strict branch hierarchy, so you need to plan ahead. Currently I suspect that main is the parent of both dev and prod so in effect to go from dev to prod you have to merge via main.
The best practice would be to take the new branch for your rewrite from main this way you have a clear path to prod once the rewrite is done, but you can still support your users in the existing dev branch.
I.e
Prod
|
Main
| |
Dev Dev2.0
As a side note, I'd try to keep your branch names as short as possible as you may start to hit the windows 260 character path limit.
For more information on branching strategies, read the ALM rangers guidance on codeplex.
Related
I have to upload a new project to TFS. This project is already finished but it is not under control version yet.
I have decided to work with two branches: main, dev. In my case release is not necessary, I can do all the stuff using feature isolation branching strategy.
Initially I create a team project. Using team explorer from Visual Studio I create two folders: Main and Dev under team project.
First I upload project to Main folder.
From now on each time a new feature must be implemented I create a dev branch from Main folder and put it under dev folder, let's say dev_branch_01. This dev branch will be short-lived.
The implementation of this feature is divided into parts. Each part is done by a developer so each developer creates a new short-lived branch from the dev_branch_01 just created in order to implement the assigned part. When all developers have completed their part, they merge their dev branch into dev_branch_01 and resolve conflicts.
Once all the parts have been merged into dev_branch_01, QA Team makes the necessary tests against this branch. When all tests are passed by QA Team, dev_branch_01 is merged into Main branch.
Here, I have a doubt: all the short-lived dev branches done from dev_branch_01 by each developer could be deleted? Also dev_branch_01 could be deleted as well?
Later in future, when a new feature must be implemented, we repeat the process again, I mean, we create a new short-lived dev branch from main branch, let's say dev_branch_02 and we repeat the entire process explained above.
We always have one main branch and many short-lived dev branches.
I would like to know if the way we work with main and dev branches is correct.
Lest break this question:
Here, I have a doubt: all the short-lived dev branches done from dev_branch_01 by each developer could be deleted?
In TFS the branch are not physically deleted, when you first delete, TFS will just Hide from the main view, image bellow. because that you can't name a branch 2 times with the same name, to reuse a name you need to force delete which I don't recommend.
So, the answer for your first question the answer is yes, it can be delete without problem, just remember, you can't create a new branch with the same name in the future.
If you want to see deleted branches click in the button Xx in your Source Control Explorer. With this option, you'll see all the history of your old branches which is good because is the kind of think that you don't have with Git ease.
Also dev_branch_01 could be deleted as well?
I don't recommend that for 2 reasons
1 - I understand that you'll want to recreate this branch in the future and like i said, you can't create a branch 2 times with the same name.
2 - With this branch alive you will be able to restore a deleted branch for any reason that you'll find and keep the history consistence between branches.
I have a project folder called as "APP1" . We are currently deploying code from this folder . we would like to create one more folder or branch so that Dev can easily checkin all their new changes without directly affecting the main folder .
Should we have one more branch of folder "APP1" so that Dev can checkin all their changes in the newly created branch and eventually we can merge all the new changes to the main folder "APP1"?
Is this a correct approach and how easy it will be for us to merge all the new changes to the main folder ?
We have team of about 4 developers working on the same project .
You can consider using Basic Branch Plan. The structure like this Development <-- Main --> Release. You can branch your project "Main" into two, one named "Development", the other one named "Release". All users can work in Development branch, after they test their code, then merge to Main branch. When you want to release your project, you can merge your code from Main branch to Release branch.
That would be one way to do it. You'll likely need to play around with differing branching and merging strategies until you figure out what works for you and your team.
There's a large guide put together by the ALM rangers for TFS branching and merging strategies. See https://vsarbranchingguide.codeplex.com/
Here's a picture from one of their guides describing the potential branching/merging strategies that may work for your team, depending on team size and release cadence:
When making a deployment to production, should I mark my code with a label or create a branch for the code that's in production?
In TFS, I would have a Release branch with a label identifying the specific version being released to production.
Which would imply you have other branches may I suggest the following
Three major branches: Main, Develop, & Release.
One Hotfix branch for your current fire.
0 to N Major-Feature branches to contain the disruption of development.
Details
Main Branch
Contains the latest stable builds
Tag/Label each release
Develop Branch
Branched from the Main
Where most of the work is done
Merge back to Main before release
Release Branch
Branched from one of the following:
The Develop branch
OR the Main branch (this may be better since it is "stable")
Bug fixes are done here
After fixes are tested and released,
merge to Develop branch
OR merge to Main branch and then forward integrate (FI - which is a merge from parent to child) to Develop
Tag/Label each release or bug fix
Hotfix Branch
Branched from Main
Merged back into Main
Forward integrate merge to Develop
Used to allow Main to remain "stable"
Major Feature Branches
Branched from Develop
Merged back into Develop
Used for major features that would possibly disrupt the regular development path
References:
another stack overflow question: when-to-use-a-tag-label-and-when-to-branch especially Martin Woodward's answer
Source Control How To by Eric Sink
A successful Git branching model by Vincent Driessen
This contains a very good graphic of a branching model
Ideally, both.
You probably want to have a label so that you know exactly what you delivered for a specific release. However, you probably also want to create a branch so that you can perform minor bug fixing to what was released and create a new release.
In practice, you could approach it in one of two ways:
Have a continuous developmental timeline that gets branched for each of your production releases:
example:
------------------------->dev
| | |
| | |
| | |
v1.0 v2.0 v3.0
Have your production releases "cascade" off of one another:
example:
---->v1.0---->v2.0---->v3.0
Ultimately, up to you in deciding what architecture to adopt, as long as it's consistent and makes sense to you.
You can use a combination of both. Here is how we do this internally for all projects.
We have structure with folder Branches and sub folder for each minor and major version. We also use labels that we set on individual sub folders so we can easily rebuild any specific version any time in the future.
$\Branches
\2012.01
\2012.02 (branched from 2012.01)
\2012.03 (branched from 2012.02)
\2013.01 (branched from 2012.03)
You can also check out Visual Studio Team Foundation Server Branching and Merging Guide for more details.
I have seen both done, Labeling is more lightweight and to me easier. But, it has been pointed out that labels can be deleted rather easily. A branch protects against this by not actually being deleted unless "destroyed". The reason I prefer not use branches is I hate having to cloak them as I tend to do get latest from the root and don't want all those branches filling up my hard drive
For the record, since it was pointed out to me about label's being deleted I have removed permissions for Labeling from everyone but Admins and the build service accounts to help mitigate this.
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
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