Oct 18, 2010 at 12:53 PM
Edited Oct 18, 2010 at 12:58 PM
We have one web application in our company that I am trying to figure out how to setup branching and merging. Let me explain our current process so you can better understand all the bases I am trying to cover.
We currently use Visual Source Save 2005 (VSS). We have several copies of the web application in VSS. They are:
3. And a copy for each developer.
Our current process has changes being released on a weekly basis. So one or more developers will get a set of changes to implement on Friday. During Friday and the next week, the changes will be made and tested. This will cause their
own personal copy of the application to check out those pieces they are working on. Once a change has been finished, the developer will check-in that code before going on to the next change.
On Thursday afternoon, all the developer's individual, finished (checked-in) changes are merged into a single build and QA will test it. This build is the new QA build. This is rolled into a production type environment for outside, 3rd party
developers to test QA against their software. It will remain in the QA environment for another week as long as there are no issues. On Thursday evening of the next week, the QA build becomes the production build.
This obviously describes a perfect process. There are a lot of points where issues can occur and they all require human intervention. For instance if a developer takes longer than a week to finish his changes, then he has to communicate
to the other developers to make sure that there are not conflicts. Also after a QA build is completed, it is up to the developer to update their copy. There are more possible issues but you get the point.
What this allows is that if there is a problem in Production or QA builds, we can deal with them because they exist seperately from the developers builds. So a developer might be 2 days into a change on their own build and we learn there is a huge
security issue with the QA build. The developer doesn't loose any work they done and they can just change over to the QA build and fix the security issue.
I just installed Team Foundation Server 2010 last week. I was looking at the Basic Branching model for us, where the Main build would be the QA build and the developers would branch off of Main on Friday when they got some changes to
make and then merge them back in on Thursday evening. Problem is that we are releasing a new Production version every week. In the Basic Branching Model the production release is a dead-end branch, meaining it doesn't get merged back to Main.
This would mean we would have 52 code branches a year. This seems excessive to me but I don't really have experience with TFS. Is this excessive?
Also, is there a better way to handle this? Conceptually, I see our QA and Production builds as as two seperate branches that should never be collapsed to a single build. Is there a mechanism to merge changes from the QA build to the
Produciton build without loosing the QA build?