Version control and website branching

Question

We have under version control(SVN) a web application. The trunk always contains the latest good version of the website.

I would like to hear how other teams manage multiple versions of the same site and how do you publish different versions for UAT, testing, Bug fixing, enhancements etc?

Let's say our biz users come along and they want a spanking new feature...So what we do is set up a new branch to do our dev. How should i publish the branch without affecting the main dev website. Should we publish each branch of the website to unique ports?

http://DevServer:80 = Trunk
http://DevServer:8081 = branch 001
http://DevServer:8082 = branch 002
http://DevServer:8083 = branch 003
http://DevServer:8084 = branch 004

Obvisouly we would have to deploy the project files to unqiue directories as well and have IIS mapped correctly....

Is this a common method? What are the best practices?

Answer 1

The RedBean book (free) gives an excellent description of branching. Although the book targets SVN, the branching strategy description applies to all.

Another good free resource is the Microsoft Team Foundation Server Branching Guidance whitepaper. It copvers:

• Parallel Development
• Branching Defined
• Creating Isolation in Team Foundation Server
• General Branching Structure Guidance
• Branching Strategies
• Broad Areas of Branching Isolation
• Creating Your Branching Strategy
• Defining Your Code Promotion Model
• Feature Crews: How Microsoft Does It
• End-to-End Implementation Scenario

Answer 2

Ideally you should be running a seperate machine for each environment (production, uat, test, dev & ci). If you don't have the resources for actual physical machines then virtualization is the way to go for the non-production environments.

This also means you can properly test the effects of the various dependencies and libraries which you use.

EDIT: About branching...

What we do here, and in a couple of places I've worked before is have an integration branch off the trunk. Developers developing new features branch off the integration branch and reintegrate into the integration branch. The CI is done on both integration and trunk. Informal testing can be done on the integration, but more formal testing (UAT releases) come from the trunk. Periodically we integrate down from the integration branch into the trunk. This has the added benefit of protecting the trunk.

i.e.

trunk
  integration
    feature1
    feature2

Answer 3

To deploy the different branches to different ports is one solution, in the Java-servlet-environment the solution to map the branches to different paths would be easier (I don't know if that is true for IIS too):

• http://DevServer:80/trunk
• http://DevServer:80/branch1
• http://DevServer:80/branch2
• ...

Both solutions should work well. If no other requirements I would choose the solution that is easier to setup and maintain with the used technology.