4

Recently been trying to setup a build server to help automate my deployment.

My question is are people using build servers like TeamCity to push changes to production (WebDeploy)servers (as well as your test server)? If so are you doing it by rebuild from source control each time or using the build files you pushed to your test server (would have also had to create all web.configs at the time you did build for test server).

user203538
  • 295
  • 5
  • 15
  • 1
    Best resource I've come across: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html#comment-308937644 – user203538 Sep 13 '11 at 23:20
  • Google "teamcity msdeploy" and you are going to find lots of resources about how to set this up. e.g. [http://www.agileatwork.com/automatic-deployment-from-teamcity-using-webdeploy/](http://www.agileatwork.com/automatic-deployment-from-teamcity-using-webdeploy/) – terjetyl Sep 13 '11 at 18:39

3 Answers3

3

It is generally a good idea to use the same set of build files you generated for your test environment deploy as for your prod deploy, as this is the only way you can guarantee that what went into the build will be consistent (i.e. in between the two builds something could have been installed on the build server or your VCS may return a slightly different set of source code files).

This is best achieved in TeamCity with the use of build artifacts, which harvest the output of your builds into a special storage area, allowing them to be drawn down in another build configuration for later use. More info in the TeamCity docs http://confluence.jetbrains.net/display/TCD6/Build+Artifact

As far as your configs go, consider using config transforms. These allow you to have a variant of your Web.config for each target environment, with different connection strings, environment constants etc. More info on MSDN http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

If you actually intend on using TeamCity to deploy to your Production environment, you may want to consider locking these down using TeamCity permissions so that only a restricted group has access to run those build configurations (in our shop this is actually a requirement to ensure seggregation of duties between Dev and Ops teams). As an added precaution, set up a separate build agent just for your Prod builds and keep it disabled until you need it (prevents you from accidentally Running a prod build configuration... yep I've been there sigh).

Dan Nolan
  • 4,733
  • 2
  • 25
  • 27
0

On a previous project we used first CruiseControl.net and later TeamCity to push changes to our test servers, we used a special NAnt target to trigger the deploy.

In TeamCity we had a build project (or it is called target in TeamCity too?) with only a manual start to trigger the install.

The install was done with a remote PowerShell script that installed our MSI packages.

Albin Sunnanbo
  • 46,430
  • 8
  • 69
  • 108
0

What I've decided to try is an MSBuild script that transforms all the configs to a location then I'm trying to create a package (well archive as I don't want as a zip file and is what i am struggling with at the moment).

So I would have this:

1st TeamCity Config:

  • Tranform web.configs
  • Build to location
  • MSDeploy to TEST

2nd Build configuration|

  • MSDeploy to production with build files and live config

Any help with achieving this would be greatful

user203538
  • 295
  • 5
  • 15