CODEWITHSUNDEEP
tfscontinuous-integrationteamcity
loyalflow
loyalflow

Reputation: 14879

TFS or Teamcity, how to automate deployment to various environments?

Looking for advice on how to handle this scenerio.

We have 3 environments: Dev, QA and Production.

Currently pushing the code to each environment is a manual process, wondering how something like Cruisecontrol or TeamCity could streamline this process.

How can we push to the various environments in an automated way?

How should TFS be setup to make this happen? i.e. master branch, feature branches etc.

Scenerio:

Developer#1 pushes their changes to the Dev and QA servers. Developer#2 pushes their changes to the Dev and QA servers.

Now we need to only push Developer#1's changes to production.

Should the main branch have only the code that should be going to production?

Upvotes: 3

Views: 3006

Answers (2)

Pablo Romeo
Pablo Romeo

Reputation: 11396

To control what gets pushed to each environment KMoraz's approach would be the correct one, using branches and merging.

Now, for build and deployment automation the latest setup I've been using is with Team City.

My setup is:

  • Trunk build: compiles on every commit, runs all unit tests, generates code coverage reports, runs FxCop

  • Static analysis build: runs nightly against Trunk, executing Duplicate Finder (Team City), ConQAT code clone analysis, StatSVN, and Resharper Code Inspections (Team City)

  • DEV Deployment (dependency on Trunk build): on every commit, if the Trunk build is successful, the application is automatically deployed to a DEV environment, using MS WebDeploy with config transformations.

  • QA Deployment: triggered manually through Team City's interface (click of a button), when moving to QA. Deploys the application to the QA server using MS WebDeploy with config transformations.

You would also set up builds for different branches, depending on your needs, especially for branches created for releases of stable versions.

The key part, is having different visual studio build configurations (just as you have "Release" and "Debug", you should have "Dev", "QA", etc), which you should use along with web.config transformations in order to get WebDeploy to configure your environment for you. That way you'd have different web.Dev.config, web.QA.config transformations, one for each build configuration, with specific settings.

There's an excellent series of posts by Troy Hunt called "You're deploying it wrong!" which guides you through the setup of automated builds and deployments.

http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html

It was very useful to me when setting this up.

Upvotes: 5

KMoraz
KMoraz

Reputation: 14164

Now we need to only push Developer#1's changes to production.

-Developer #1 checked-in his code to the Dev branch. After QA verified his changes, now you merge the changes to the Main branch and build a release for production from the Main.

Should the main branch have only the code that should be going to production?

-Yes. Ideally, production releases should be built from the Main branch.

How can we push to the various environments in an automated way?

-In TFS, a common practice is defining a build defintion per branch and/or build type. Apart from the source and build type, each defintion can also have its own tasks, I.e: run unit tests, publish to certain folders, deploy build artifacts to Lab Management, etc.

ProjectName-Main-Gated 
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI

Upvotes: 1

Related Questions