I would also caution you against using cherry-picking for selectively releasing features while holding other features out of the release.
I blogged on this challenge a while back: http://blogs.msdn.com/b/billheys/archive/2011/01/19/branching-sprint-is-done-some-features-are-not.aspx
http://blogs.msdn.com/b/billheys/archive/2011/01/19/what-is-a-cherry-pick-merge-and-why-do-you-recommend-against-them.aspx
This was developed as a Microsoft-internal lab for delivery at our internal (TR) training event.
Regards,
Bill Heys
The team is planning to deliver the final Visual Studio 2012 associated RTM release
end-August!
The purpose of this project is to build some insightful and practical guidance around branching and merging with Visual Studio Team Foundation Server by the Visual Studio ALM Rangers . The new guidance builds upon the previous release with some updates to the core materials as well as guidance on additional scenarios that include guidance for sharing resources in Team Foundation Server via branching, Database/BI scenarios, baseless merging, and new features in Team Foundation Server such as local workspaces.. The new release focuses on Hands on Labs and includes lots of lessons learnt from the community Q&A.
Branching and merging of software is a very large topic. It is an area where there is a lot of maturity in the software industry. This Ranger solution focuses on applied and practical examples of branching that you can use right now. The guide includes discussions around branching concepts and strategies but also focuses on practical hands-on labs.
This guidance is created by the Rangers who have the mission to provide out of band solutions for missing features or guidance. This content was created with support from Microsoft Product Group, Microsoft Most Valued Professionals (MVPs) and technical specialists from technology communities around the globe, giving you a real-world view from the field, where the technology has been tested and used.
The content is packaged in separate zip files to give you the choice of selective downloads:
The recommended method is to simply post ideas to the community or to contact the Rangers at http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx.
Post comments on the Discussions page.
The team is planning to deliver the final Visual Studio 2012 associated RTM release
end-August!
The purpose of this project is to build some insightful and practical guidance around branching and merging with Visual Studio Team Foundation Server by the Visual Studio ALM Rangers . The new guidance builds upon the previous release with some updates to the core materials as well as guidance on additional scenarios that include guidance for sharing resources in Team Foundation Server via branching, Database/BI scenarios, baseless merging, and new features in Team Foundation Server such as local workspaces.. The new release focuses on Hands on Labs and includes lots of lessons learnt from the community Q&A.
Branching and merging of software is a very large topic. It is an area where there is a lot of maturity in the software industry. This Ranger solution focuses on applied and practical examples of branching that you can use right now. The guide includes discussions around branching concepts and strategies but also focuses on practical hands-on labs.
This guidance is created by the Rangers who have the mission to provide out of band solutions for missing features or guidance. This content was created with support from Microsoft Product Group, Microsoft Most Valued Professionals (MVPs) and technical specialists from technology communities around the globe, giving you a real-world view from the field, where the technology has been tested and used.
The content is packaged in separate zip files to give you the choice of selective downloads:
The recommended method is to simply post ideas to the community or to contact the Rangers at http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx.
Post comments on the Discussions page.
Actually I will move this to a new discussion.
We are a new Business Intelligence (BI) development team and whilst we are attempting to model a TFS branch plan that is easily manageable / automated I'm interested to hear how other in the Microsoft BI space are managing BI development through TFS.
Our IT team have a comprehensive TFS Workflow and Branch management scheme in place for their OLTP development, the BI side still requires TFS but not with the same complexity, after all BI has to be very nimble yet thoroughly tested etc.
Would love to hear thoughts on this.
We are a new Business Intelligence (BI) development team and whilst we are attempting to model a TFS branch plan that is easily manageable / automated I'm interested to hear how others in the Microsoft BI space are managing BI development through TFS.
Our IT team have a comprehensive TFS Workflow and Branch management scheme in place for their OLTP development, the BI side still requires TFS but not with the same complexity, after all BI has to be very nimble yet thoroughly tested etc.
At present our surfacing technologies are the MS suite of tools e.g. PPS, SSRS, Powerview, Powepivot , Excel etc we use the SQL2012 Technology stack for DW/DM and Cubes, SharePoint 2010 for publication to the business.
Would love to hear your thoughts and ideas, experiences in this area.
Many thanks
Paul
This is a temporary post that was not deleted. Please delete this manually. (b4f3333e-86fe-461f-b8f6-fc4223a05c6a - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
The purpose of this project is to build some insightful and practical guidance around branching and merging with Visual Studio Team Foundation Server by the Visual Studio ALM Rangers . The new guidance builds upon the previous release with some updates to the core materials as well as guidance on additional scenarios that include guidance for sharing resources in Team Foundation Server via branching, Database/BI scenarios, baseless merging, and new features in Team Foundation Server such as local workspaces.. The new release focuses on Hands on Labs and includes lots of lessons learnt from the community Q&A.
Branching and merging of software is a very large topic. It is an area where there is a lot of maturity in the software industry. This Ranger solution focuses on applied and practical examples of branching that you can use right now. The guide includes discussions around branching concepts and strategies but also focuses on practical hands-on labs.
This guidance is created by the Rangers who have the mission to provide out of band solutions for missing features or guidance. This content was created with support from Microsoft Product Group, Microsoft Most Valued Professionals (MVPs) and technical specialists from technology communities around the globe, giving you a real-world view from the field, where the technology has been tested and used.
The content is packaged in separate zip files to give you the choice of selective downloads:
The recommended method is to simply post ideas to the community or to contact the Rangers at http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx.
Post comments on the Discussions page.
epub format (for tablets/phones) would be great addition
Hello,
I'm implementing a branching scenario in our TFS project. Here is the basic plan :
Dev <-> Patch <-> Hotfixes
Dev is branched to a "Patch" branch each major(X.X.0.0). A designated "Patch" branch contains all the patches versions (..X.0) for the associated major. Finally I can branch "Patch" from one of its version to create a hotfix (...X).
It seems to work well for 95% of my needs but sometimes I have to create a hotfix which contains changes of some previous hotfixes. With my scenario I can't easily do that. Is there any possibility or is it some bizarre need :) ?
Which branch is your trunk? Is it what you label as Dev? The trunk or main branch would be the root of all other branches, and the place to which you do reverse integrations.
Do you ever do reverse integrations to capture the fixes represented by your hot fixes?
Yes "Dev" is my trunk ans is the root of all other branches. A hotfix is always RI in "Patch" and then in "Dev".
I was thinking of a cumulative branch of hotfixes for each version of patch and then branch it to actually make a patch, but I couldn't select particular hotfixes to make a "mix".
From what I read a hotfix is, most of the time, targetting one customer but how do you allow them to install several hotfixes without losing changes from previous one (like Microsoft's KB).
I am confused. You say you Reverse Integrate(RI) all hotfixes back to Patch. So Patch accumulates every hotfix. But you say you cannot get previous hotfixes in subsequent ones. If you are doing RI from each Hotfix back to Patch and Dev, then when you make a branch from Patch for a future hotfix, it should have all previous hot fixes. Are you doing RI for every hotfix or not? Is your branch design a proposed theoretical one or one you have been actually using it for some time?
Also, I am not clear on your hotfix approach. Are you sending the customer an entire package of the product with a special fix embedded in it? Or a piece of add-on code that will modify a base installation. Those are drastically different approaches and the final result of all this depends on the answer to both of these questions: whether you RI hot fixes, and how you deploy them.
If you reveal a little about your underlying technology platform (like WIndows Forms vs ASP.Net web forms, etc...) it may help.
Thanks for your help and I'll try to explain the best I can our process. First of all our branch design is quite theoretical at the moment.
Then yes, every hotfix is RI in the "Patch" branch in its current version (we may have 4 or 5 patch version of a major). When I make a hotfix I can only branch "Patch" from the version to fix. Let say 5.2.3.1 is a hotfix of 5.2.3.0 (this is our non-standard way of versionning), this fix is then RI in "Patch" (which can be in developpement for 5.2.4.0 or further). I'd like to be able to make other fixes with changes of 5.2.3.1 but I can't branch "Patch" from its latest version for obvious reasons.
Our project is based on ASP .NET web forms and consists of several DLL and other ressources. We aren't always sending a complete new setup of the software but it may happen for easy replacement.
From: msauvaget
Thanks for your help and I'll try to explain the best I can our process. First of all our branch design is quite theoretical at the moment.
Then yes, every hotfix is RI in the "Patch" branch in its current version (we may have 4 or 5 patch version of a major). When I make a hotfix I can only branch "Patch" from the version to fix. Let say 5.2.3.1 is a hotfix of 5.2.3.0 (this is our non-standard way of versionning), this fix is then RI in "Patch" (which can be in developpement for 5.2.4.0 or further). I'd like to be able to make other fixes with changes of 5.2.3.1 but I can't branch "Patch" from its latest version for obvious reasons.
Our project is based on ASP .NET web forms and consists of several DLL and other ressources. We aren't always sending a complete new setup of the software but it may happen for easy replacement.
Read the full discussion online.
To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)
To start a new discussion for this project, email vsarbranchingguide@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
