jrummell's questions

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?

I'm trying out WinHost and I'm running into some issues with sub-domains. On WinHost, you can have multiple sub-domains per hosting account, but each sub-domain points to the root website. E.g. you can have www.example.com, sub1.example.com, and sub2.example.com but all of them display the content at http://www.example.com/.

Other Hosts allow you to point sub-domains to a sub folder in your website. This would allow you to point sub1.example.com to /sub1, sub2.example.com to /sub2 and www.example.com to /.

WinHost recommends using an asp/aspx page to redirect http://sub1.example.com to http://sub1.example.com/sub1, which points to /sub1. While that would work, I'd like to not have the subdomain in the url twice.

So I tried using IIS7 URL Rewrite to point http://sub1.example.com to /sub1. Ben Powell describes this in detail on his blog. This is great, except Request.ApplicationPath is now /sub1/path/to/current/page.aspx, which breaks ASP.Net Themes (and probably other stuff too).

What can I do to fix the ApplicationPath? Is there a better way to accomplish this?