In my understanding a major point in Continuous Deployment is (well, obviously I guess) that deployment is automatically done as a part of the building process.

Conceptually it is easy to understand how the deployment can be done when the target is a website. However it appears hard/impossible to continuously deploy when it is a desktop application deployed via an msi-installer (sorry for my tech background being mainly a Microsoft one)?

Are there deployment technologies that cannot be used when continuously deploying? Or rather: Which deployment technologies makes sense in continues deployment?

6 Answers 6


I'd suggest a two step process. Building creates the installer, which goes out to your server. The client machines are set up to pull the installer on startup/midnight/maintenance window and run it silently.

So you continuously build throughout the day, but the live systems grab the new installer at the appropriate time. It's not so much a matter of having any one thing do all the work of the build/deploy cycle. The point is having all of it automated which is a different animal.

The classic example is having a robot cook a meal. Most people start designing how the robot will open the door to the fridge, check produce by feel, so on and so forth. But a proper design throws out the concept of a kitchen! A robot for cooking would be the whole room. There would be a part that opens the prebagged produce, already determined correct, and moves it via conveyor belt to the stove. At the stove, multiple arms with built in utensils would begin whipping up the output product. The thing doesn't need hands, it doesn't need legs, it almost doesn't need eyes.

Your build system should not be: "take what a person would do/currently does and have a program step through it exactly." Start from what you want to accomplish. When your process does that, the deploy is done, wherever you've defined that to be.


Given you've mentioned Windows Installer and MSI's, I guess you're mostly interested in deployment of client/desktop style apps? Automatically deploying to the build server itself should be relatively straightforward (by triggering a silent install as suggested by other posters) - for testing purposes this would only make sense for server apps (or in a really small team where the tester was using the build server itself).

The best solution I can think of if you want to push the install to testers' own machines is to use group policy deployment on the domain to roll out builds (see http://support.microsoft.com/kb/816102) This will require a manual step to publish the update, which is not ideal for your purposes (if slightly important for network security :-)) It also requires you to have admin privileges on the domain controller, which might be a limiting factor depending on the size/structure of your organisation!


A great example to look at/steal from is google chrome -- they do continious, silent deployment on Windows. Without requiring administrator approval.

The main trick, as I understand is just using Microsoft Click-Once deployment combined with deploying to the %userprofile% rather than %programfiles% but I could be really wrong.


The problem generally is that you do not want to continuously deploy if the test box is in-use, imagine the carnage as testers are logging bugs against v567 of the app, but actually they are (silently) running v568!

So, I never actually continuously deploy at all. I package the app up (and copy all the binaries into relevant directories so users can pick a particular one if necessary) and let them install themselves. Usually they do that first thing in the morning, via a script.


MSI's can install in silent mode (where you just launch the EXE and let it finish). This would be great for unattended mode.

If you need to actually test the installer, then consider writing a robot that can "taste" what is on the monitor, locate buttons and press them, and enter text in text fields. In other words, as you would blackbox test any other GUI application.


We have our build server configured to push the artifacts to an SVN repository. The testers are all working from a checked out copy of that repository and when they need/want/told to update it is simply a matter of them right clicking on the top level directory and selecting Update (TortoiseSVN).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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