Tools for managing code deployment/versioning for IIS / Windows enviroments

Question

I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.

Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.

I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).

Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.

So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.

Thanks.

Answer 1

First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).

Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.

In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).