I would like to know how you can set up an IIS server to pull updated, pre-built packages from the internet. Bonus points for minimizing the necessary adjustments to the server.

setting: The company I work for builds custom web applications for various clients. Often the clients want to host these applications themselves on their internal servers. The web sites are often not even available from outside the corporate network, let alone the server's administration interfaces (file copying, remote desktop etc.)

Secondly, we have found that development without a continuous deployment strategy leads to error prone releases, and we have decided not to do that anymore. We need frequent releases (multiple times a day) using a fully scripted build process (building, deploying, sql server migrations, everything)

current approach: So we now have a Jenkins CI server on our network that is accessible over the internet on a specific port. We ask the client for three machines/vms: A Production server, a staging server and a build machine. (and some sql databases usually) The programmers need to be able to log on, and have administrator privileges on the build machine. The build machine needs to be able to copy files to the web server and access the database. We then each time

  1. configure a build & deployment process on the build machine
  2. launch a Jenkins client on the build machine so that we can periodically trigger a build on the build machine and get reporting on those builds

The problems: We're now configuring a build machine for each client, which takes time (reinstalling MSBUILD, nuget all the dependencies etc.). We're also requiring each client to connect a machine inside the highly protected parts network to a server that in effect allows the execution of arbitrary shell scrips. We therefore can only allow a super select group of people access to our jenkins server, which makes those people a bottleneck.

What we would like: To create a build machine on our own network, have that machine create packages and install those packages on the clients machine. Our package host won't be able to initiate a connection to the client's machine (because the client's machine isn't accessible over the internet), so the the IIS server needs to poll for new package versions. Since the deployment of the website is not the administrator's main task configuring the IIS machine shouldn't require a lot of work. It should also not give the creator of the package(i.e. us) too much control of the machine. Preferably the package should provide the files and IIS configuration and not much more.

My question: I'm not familiar with recent developments in packaging and system administration. What approach can I use to implement the process described above? I've read up on Web Deploy, WIX, various CI servers and octopus deploy, but all seem to require extensive configuration on the client's network, or administrator access to the IIS machine.

Does anyone here now how to reach our goals?


I don't think you're going to get around installing some sort of agent on clients' machines to poll and keep sites updated. Octopus Deploy seems like a good bet, can you detail why you've discounted that already?

You could also take a look at AppHarbor (I'm co-founder). It's a full-service .NET platform, but you could just take advantage of the, currently free, CI-parts and use API build notifications to be notified of and grab build-packages that you then deploy yourself.

  • I thought octopusdeploy required setting up a whole server on the client, which might require a lot of permissions and a lot of sysadmin work. Installing one program on the iis server would be okay i guess. I'll check out appharbor, i haven't seen it before. – Jauco May 17 '12 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.