Automated Deployment using CI server

Question

In our project, deployment is always a pain, mostly because of the mistakes done by the release management team. Either they screw up the configuration or get the wrong version installed somehow. We use teamcity as our CI server, and it produces the artifacts as zip files(dll's and exe) which is usually passed on to the release team. My question is, is there a way to automate the whole deployment process?

Is there a commercial tool, which supports this?

We will want to do the following:

• Update the config files with environment specific values.

• Install windows services to the server.

• Upload the UI(WPF) bundle to the centralized location(which is pulled down by another application, sort of a launcher).

• Change the DB connection strings.

Do all the above for various environments(like int,uat and prod)

DB deployment since is a separate beast as such, need not be covered in this.

Any best practices, tools or solutions will be highly helpful.

Thanks, -Mike

Answer 1

I have used TeamCity for some fairly large projects and I have automated every aspect of deployments apart from the database. The main steps I use for each project are:

1. Get a TeamCity agent installed on the production server
2. Have the build get everything out of source control (you do have everything in source control right?).

3. Have a build step that builds and publishes your solution. This can be achieved by adding the following command line argument to your MSBuild call:

   /p:Configuration=[Your Config];DeployOnBuild=True;PackageAsSingleFile=False

   Your published files (and tranformed config files) will be written to the following directory:

   [Your Project Directory]\obj\[Your Config]\Package\PackageTmp

4. Using a scripting language (in my case Powershell) to copy the published artifacts to your deployment directory and make environment specific changes you mentioned. E.g. extracting archives, copying files, starting/stopping websites etc..

5. Run any automated testing (e.g. nUnit, Selenium etc...)

I find the best strategy is to have a .Net post-build event that invokes an appropriate powershell script passing in relevant details like the solution path and configuration name (alternatively, I have also had TeamCity pass the environment name to the Powershell script) so that it knows what it needs to do (e.g. Staging, Production etc...). You should find that a scripting language like Powershell can do everything that a person can do (and about 100x faster and 100% reliably).

There is so much content on Powershell out there that you can just google anything you need to do in Powershell and you will get an example. E.g. "powershell deploy WPF", "powershell upload FTP" etc...

In a previous job I needed to deploy windows services remotely and I found that with enough research, I was able to get the MSI for the service to uninstall the existing service and install the new one completely silently (i.e. no dialogs). This will help a lot in your quest for automation. I can elaborate on this if you would like.

Below is an example of a Powershell post build script I generally use:

Note how I use some default parameter values so that I can execute the script directly from my Powershell editor to simulate and test different configurations on my local machine.

param(
    [string]$configurationName="Debug",
    [string]$sourceDirectory="C:\SVN\<Your local solution location>")
Set-StrictMode -v latest
$ErrorActionPreference = "Stop"

# Load required functions
$private:scriptFolder = & { (Split-Path $MyInvocation.ScriptName -Parent) }
. (Join-Path $scriptFolder DebugBuild.ps1)
. (Join-Path $scriptFolder StagingBuild.ps1)
. (Join-Path $scriptFolder ProductionBuild.ps1)
. (Join-Path $scriptFolder CommonBuildFunctions.ps1)

#Execute appropriate build
switch ($configurationName) {
    "Debug" { RunDebugBuild $sourceDirectory }
    "Staging" { RunStagingBuild $sourceDirectory }
    "Production" { RunReleaseBuild $sourceDirectory }
}

To execute a publish on development machines, I setup a VS publish profile for the solution that is committed to SVN so the other developers can use it. This profile publishes directly to the local deployment directory.

Answer 2

We use TeamCity for our deployments in addition to CI and it works really well. Here are a couple things that may help:

• If you're using VS2010, check out the SlowCheetah plugin. It can do the config file transforms to do what you need to replace DB connection strings and other environmental-sensitive variables. These transforms happen automatically when you build based on the selected build configuration.
• Check out MSDeploy. While it gets most of it's attention for deploying web applications, it can do a lot of other things, like installing windows services and syncing files to a destination directory. While most people install it as an IIS add-in, it can be installed as a separate service that has no dependencies on IIS.

If you're not using VS2010 (or don't want to use SlowCheetah), here's how we you could handle the config settings:

• Create an app config for each different environment (I'm assuming you have a build configuration set up for each environment). Add the configuration name to the end of the config file, so in Prod we have App.config.Prod and QA we have App.config.QA.
• Put your complete configuration for each environment in it's respective config file for that environment.

• As part of your build (we use the "BeforeBuild" target in the project file), use msbuild to copy the environmentally specific app.config over the actual one. Here's a custom msbuild target we use to do this:

  <PropertyGroup>
      <EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig>
  </PropertyGroup>
  
  <Target Name="ReplaceAppConfig">
      <Message    Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" 
                  Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" />
  
      <Message    Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
                  Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" />
  
      <Copy   SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)"
              DestinationFiles="$(ProjectDir)App.config"
              Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" />
  
  </Target>
  

Let me know if you need any other details.