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

How to Handle Continuous Releases

Oct 18, 2010 at 1:53 PM
Edited Oct 18, 2010 at 1: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:
1.  Production
2.  QA
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?

Oct 18, 2010 at 4:49 PM

After doing your tutorial, it seems to me that I can follow the same format we had on VSS.  I would start with a Main of the application.  From there I would make branches for each Dev and a QA branch.  From the QA branch I would make a further branch for Release.  Does that sound like it would work?

Developer
Oct 19, 2010 at 2:43 AM

It should not  be necessary to make a separate branch for *each* dev. Developers in TFS have workspaces which gives a developer isolation from the common Dev Branch. The Dev branch is branched from Main. Developers check code out of the Dev branch into their workspace. Then the devs check their changes into the Dev Branch. In our guidance, the Main branch is the QA branch. Code from the Main branch is *deployed* to the QA environment, not branched from Main. When the Development team is ready to do a release, they would merge Dev to Main and deploy Main to QA for testing. When QA signs off on the release, you would branch Main to Release. After branching for release, bugs can be fixed in the Release branch and merged back into Main.

Don't worry too much about having 52 release branches per year. You can make a decision to keep only the most recent n release branches. There is not a lot of overhead to making a release branch. TFS only keeps a delta. When a branch is first created, it is identical to it's parent branch (no delta) so not much overhead. If you start making changes in the Release branch to fix bugs, the delta for those changes will be stored for that release branch.

Regards,
Bill Heys
VS ALM Ranger