TeamCity
Powerful CI/CD for DevOps-centric teams
Automating Deployments with TeamCity and Octopus Deploy
This guest post is brought to you by Paul Stovell, creator of Octopus Deploy.
Octopus is a deployment automation server for .NET developers. Octopus takes over where your build server finishes. The build server builds the code and runs tests, while Octopus takes care of deployment.TeamCity is a powerful continuous integration and build automation tool. Scroll through the list of built-in build runners and build features in TeamCity, and you’ll find almost any activity that you could want to perform during a build. It can restore NuGet packages, compile solutions, run unit tests, patch AssemblyInfo files, inspect code quality, and capture code coverage metrics, just to name a few. You can also combine multiple builds together to form a chain of builds, which is a powerful way to orchestrate an entire continuous delivery solution.
TeamCity can also be used to deploy your application during the build. This is useful if you want to deploy it to a test environment for users to test, or even automate deployments straight to production. You can even chain builds in TeamCity to make promoting between Test and Production environments possible. You can do this by telling TeamCity to call your script or command-line deployment tool during the build:
Unfortunately, while TeamCity provides some high-level build activities like compiling with MSBuild or running NUnit tests, it doesn’t provide any high level deployment related tasks (“Configure IIS”, “Install a Windows Service”, “Update this configuration file”, etc.). “Run a script” is where TeamCity begins and ends; it’s up to you to write that script. Most teams solve these problems themselves, by writing their own deployment automation scripts, by combining tools like WebDeploy and PowerShell Remoting. Along the deployment automation journey, teams often encounter similar problems:
| Binary distribution Many files are needed to deploy an application. Binaries (DLLs, EXEs), CSS and JavaScript files, images and other assets, configuration files, and so on. How do we distribute these files to remote machines? How do we do this securely and ensure no tampering when transmitting over insecure networks? |
FTP(S); rsync; file shares; WebDeploy |
| Remote execution Some tasks must execute directly on the remote machine (e.g., configuring IIS sites and Windows Services, installing COM components, making registry changes). How will we invoke these tasks? Is it easy to read the output? How will we detect failures? How do we deal with authentication? |
SSH; PowerShell Remoting; WinRM; WebDeploy; PSEXEC; Remote Desktop |
| Configuration differences Each environment is different. Different connection strings, different network paths, different credentials, etc. How will configuration files be modified? |
Multiple copies of files renamed during deployment; XPath transforms; .NET Configuration transform files; PowerShell |
| Parallelism Deployments often involve many machines. How do we distribute files and install applications in parallel to keep downtime to a minimum? What if each server has different settings? |
Custom logic in scripts. Be careful to maintain it and not treat it like throwaway code. |
| Visibility and security If different steps in the deployment run on different machines, how will we handle authentication/authorization? Can we allow testers to deploy to Test but restrict who can deploy to Production? Are changes audited and easy to roll back? Can anyone on the team easily see what is deployed where? |
TeamCity dashboards; chained builds; build permissions |
Four years ago, these were the kinds of problems we faced when it came to writing our own deployment scripts for client projects. We wanted something that elegantly solved the problems above, and which could work in the most secure environments, and yet would be as easy to use as the high-level build runner tasks in TeamCity. That’s why we built Octopus Deploy. Where TeamCity is a build automation server, Octopus is a deployment automation server. Like TeamCity, Octopus is free for small teams. When you use TeamCity and Octopus together, the goal is to let TeamCity do what it does best – build – and let Octopus take care of deployments. 
TeamCity is responsible for:
- Detecting source control changes
- Compiling the solution
- Running unit tests
- Inspecting code, gathering build metrics, etc.
- Packaging the application ready for deployment
- Using our TeamCity plugin, notify Octopus that a new release is available
While Octopus is responsible for:
- Distributing the packaged applications to the remote web/application servers, all in a secure way
- Extracting and installing them
- Modifying configuration files with environment-specific variables
- Configure IIS, install and update Windows Services, etc.
- Invoking any custom deployment actions on the remote machines
- Gathering all the deployment logs into a central place
And just as the dashboard in TeamCity gives you an overview of your builds, the dashboard in Octopus gives an overview of your deployments: 
If you have a build pipeline in TeamCity, extending it to deployment can do wonders in giving your team a tighter feedback loop. Writing your own custom scripts and invoking them from TeamCity isn’t the only option; the next time you find yourself automating deployments from TeamCity, have a look at Octopus Deploy.
Subscribe to TeamCity Blog updates
