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:
- Get a TeamCity agent installed on the production server
- Have the build get everything out of source control (you do have everything in source control right?).
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
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..
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.
