TeamCity works great as a Continuous Integration server, but after the build is done it doesn’t give you a deployment behavior out of the box. The following steps are a guide to configure TeamCity to perform such task. With the right modifications it can be adapted to different technologies and platforms.
Lets take a simple project as an example. This is a windows service that makes a wake up call to a remote webservice. In TeamCity/Administration create a new project called WakeUpService. Then add a build configuration, this will compile the project and create the artifacts for us. It is a .NET project so the build step of the build configuration will be set to Visual Studio (sln).
Now, we need to add another TeamCity build configuration for that same project but in the build step we can select another build runner, in my case I selected MSBuild (I recommend reading Inside The Microsoft Build Engine for the ones not familiar with MSBuild).
There are then two configurations for the project WakeUp:
- WakeUpService: To build the artifacts of the project.
- Deploy WakeUpService: To deploy the artifacts built by WakeUpService.
To deploy the same artifacts to different machines we can use the TeamCity build agents. We can install them in each of the computers we want to deploy the code and use them only to execute the deploy builds. The MSBuild task file (build.proj) will be executed in that machine.
In order to deploy we can do the following tasks:
- Resolve the artifacts (that are going to be deployed).
- Uninstall a previous version of this service.
- Replace environment variables.
- Execute database scripts.
- Copy artifacts.
- Install the service.
- Tag the build on TeamCity.
In the next blog post I will go through each one of those tasks explaining how to accomplish them.
