7

My team uses TeamCity for continuous integration. It will build, test and deploy web applications via Web Deploy to dev and qa web servers. The tricky part is deploying to a production web server - our policy dictates that developers cannot deploy to production, only a system administrator can.

Our current approach is to have TeamCity build a web deployment package, which the administrator can download and install on the production web server. However, we'd like to allow them to simply click "Run" on a build configuration, but we're not sure how to secure that button.

We could create a TeamCity project that only administrators have access to, but we also have to address Web Deploy security. The Web Deploy service needs to be authenticated with a local admin account on the production server. We don't want developers having access to the username/password in a build script, nor do we want every build agent running as this account since developers could create a build that uses it to deploy to production.

I've haven't had much luck finding resources on TeamCity security/deployment best practices, but I can't imagine we're the only company in this situation. How do others manage automated deployment security?

jrummell
  • 185
  • 2
  • 9

2 Answers2

5

Using the roles and permissions in Teamcity, you can have a project that only your deployment team has access to. It can have an artifact dependency on the main build, and you can even have it used "last pinned build" so developers can control what's even available.

I would install a build agent that is able to deploy to the target system(s), and then use the "compatible builds" feature of that agent in the TeamCity UI to make it only compatible with your production deployment build. (Of course you'll also want to ensure your developers don't have permissions to modify agent configuration.)

This is one downside of Teamcity using Agent compatible configurations options: if you leave your other build agent(s) as compatible with all builds, then the production deployment may be attempted from one of them if free. The only workaround I know of is to set them all to only run "specified builds" and add all other builds to the other agent(s). The pain is if you add a new build, it won't be able to run anywhere until you specifically add it as compatible.

There are another couple ways to restrict the build to only run on specific agents using Agent Requirements in the build configuration.

One is to add a requirement that teamcity.agent.name equals the agent name you want it to run on. (or conversely, Does Not Equal the one you don't want it to run on).

Another is to add a requirement for an environment variable (exists, or with a specific value) and then only set that environment variable on the agent(s) you want to be able to run that build.

Another possible solution is to have two installs of Teamcity, since you effectively have two different sets of users. You obviously can't use an artifact dependency, but you can always get to the latest artifacts of a given build using a url like: * http://teamcity.server/repository/download/bt41/latest.lastSuccessful/setupfile.exe

where:

  • bt41 is the build id in Teamcity (you can find it in the URL when you navigate to any build)
  • latest.lastSuccessful can also be lastest.lastPinned, `latest.lastFinished, or the exact build number
  • setupfile.exe is the file you want to grab from the artifacts output (this can also be a path, if it's not published in the top-level)
gregmac
  • 1,459
  • 3
  • 18
  • 27
  • I didn't know about the "Run selected configurations only" agent option. That will be useful, but as you said, annoying to maintain. I think I saw an article on sharing build dependencies between servers, I'll see if I can find it again. – jrummell Oct 20 '11 at 12:11
  • I remembered another way to restrict agent use, edited my answer. I actually just learned about using agent.name as a requirement, I think I actually might go modify my teamcity config. – gregmac Oct 20 '11 at 13:34
  • We did a combination of compatible builds and agent name requirements so that the agent can only run production deploy builds and those builds can only run on that agent. – jrummell Oct 27 '11 at 13:12
  • An interesting note - somehow TeamCity determined that the agent was capable of running all of our .NET builds even though it doesn't have VS or Windows SDK. That's why we needed both agent restriction methods. – jrummell Oct 27 '11 at 13:13
  • @jrummell - it's "capable" because there are no defined conditions that say otherwise. There are built-in variables you can use, such as "VS2008", "VS2010", "DotNetFrameworkSDK4.0_x86", and you can define those as requirements (using "exists") on the build. – gregmac Oct 31 '11 at 16:38
2

For securing the web deploy process, if you are on a domain, you can setup web deploy to accept windows authentication and then have the teamcity build agent run as the domain user who has permission to deploy in IIS. I have things setup this way, and you do not need any kind of passwords in the web deploy script.

Setting up windows authentication for web deploy: http://blogs.iis.net/carlosag/archive/2011/12/13/using-windows-authentication-with-web-deploy-and-wmsvc.aspx

Blake B
  • 21
  • 2
  • Whilst this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Scott Pack Oct 20 '12 at 18:25