Currently our CI process is built entirely in Teamcity. We have multiple projects for an environment type deployment, e.g. Develop, QA, UAT. Within each build configuration, we have a custom build step which works in the following way:
- We have defined custom MSBuild scripts that are local to each project, e.g. \Project\Build\deploy.target. This file performs the build, collation of files, and deploys the files to the enironment required (using build parameters defined in Teamcity).
- We have defined a custom Powershell script that creates IIS websites, databases etc
What I’m looking for, is guidance to migrating to using Octopus deploy. I’ve seen varying options, with some using Octo.exe as a release runner. Does this mean that Teamcity is what triggers a deployment? What is the benefit of Octopus deploy in this instance?
What you have is essentially what Octopus does. I’d say that using Octopus would allow you to streamline it, so that there’s less to maintain in your Deploy.targets file, and possibly less in your powershell scripts.
Octopus also takes care of pushing the files and configuration to the remote machines securely, in case that helps.
With Octopus, you’d have TeamCity package up the application into a NuGet package. You’d then use our TeamCity plugin to trigger a deployment in Octopus once the build completes. Octopus would take care of pushing the files to the machines, unpacking them, and configuring them securely.
I’d say the benefits would be:
- Less code to maintain, especially since you may want to start deploying many more projects in the future and don’t want duplicates of deploy.targets laying around
- A single dashboard where your team can easily see what’s deployed where
Hope that helps,