views:

259

answers:

3

We have 3 environments: dev, test, and staging.

I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?

A: 

Yes, this is possible, but you must manually check them in from one branch to another.

benjy
+2  A: 

You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.

Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.

Two important notes:

  • Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
  • In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.

Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).

Patrick Karcher
Richard Berg
Richard Berg
+4  A: 

Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.

Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.

Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.

Wim Hollebrandse
The branching guidelines that I have read (http://www.codeplex.com/BranchingGuidance) suggest having a main branch, a production branch, and various dev branches that can be merged into main/prod as necessary. I see several benefits including parallel development, the ability to deploy a variety of versions, the ability to debug prod versions while developing and testing new releases, etc..
Mayo
My branching guidelines are less Microsoft and TFS centric I guess, and apply generally. Branching for an environment seems a ridiculous option IMO, all that differs is the odd configuration file/setting etc.
Wim Hollebrandse
If you can be nimble enough to avoid permanent stage branches, that is good. One danger in having permanent stage branches (that I struggle against) is that it makes management comfortable with slow deployment, which is really *bad*, I'm sure you'll agree; undeployed code just slowly oozes up the stack. Since our situation/contracts mandate this, I try to use the advantages of the permanent stage branches while minimizing the disadvantages. I certainly like having our too-long evaluation stages out of the way; often we can have just the one dev trunk and no dev branches.
Patrick Karcher
Richard Berg
If you have TFSBuild set, then you can use a tool called 'TFSDeployer' that does just that, when the BuildQuality of a build is changed, it will start a customizable script which can be written in powerscript i believe. The tool can be found on Codeplex
Bart Janson