Question

I have been tasked with looking into our deployments, and seeing where they can be streamlined. Right now we have 4 different configurations (Debug/Dev, Test, Staging, Release) and 4 *.config files. We have a task that will overwrite app/web.config with the appropriate *.config pre-build time based on the active configuration. An MSI is created, and we do a full deployment of the component on release night.

This is not entirely ideal because if we change something in a config file, or fix the spelling in a specific view we have to re-deploy the entire thing. Not to metion that the MSI will occasionally require a reboot. One other option that has been brought up is instead of creating MSIs we could create custom deployment/rollback scripts and have the ability to do incremental release.

Has anyone here tried deployments both ways? What are some of the pros/cons you have found? Is there a third way we haven’t thought of?

edit: Just to clarify a few things…We don’t deploy to customers. All software is deployed to our servers. (a few sites, and a lot of windows services). We never change things in production. We actually use the built in system within VS to create the MSI, so that part isn’t the terrible part. To me it just doesn’t make sense to redeploy an entire website if you had to change 1 view. We also have to deploy to multiple servers. Right now that is done by running the MSI on each one.

Answer 1

MSI pros:

• Application/service/site gets installed and registered like most other Windows apps, and shows up in Add/Remove programs
• Some built-in support for re-installing, upgrading
• Has some built-in support for installing Windows services/IIS sites/lower-level Windows features

MSI cons:

• Seems really cryptic once you get “under the hood”
• Seems more difficult to customize than using a custom script

Script pros:

• Easier to customize, although certain steps might require lots of/cryptic scripting (working with IIS, lower-level computer administration)
• Don’t have to deal with low-level weirdness of MSI

Script cons:

• .bat scripting is not the most readable or writable language. (Powershell is better, but then you have to worry about whether Powershell is installed on the target machine).
• Low-level operations require a lot of administrative scripting for commit/rollback behavior
• No built in support for installing or rolling-back (MSI has some support built-in)

One thing I’ve come across that helps with MSIs is WiX (http://wix.sourceforge.net/), but even WiX seems pretty cryptic in a lot of ways. We use a combination of MSBuild and WiX to do automated builds and deployment/installs, and it works okay for us.

Overall, I’d probably lean more towards doing MSI/WiX (or other installer toolkit) deployments over scripts. MSIs are the standard way of doing installs on Windows, and once you get it working, you usually don’t have to change too much. MSBuild or some other build framework (NAnt, etc.), can be useful for setting up the deployment (renaming files, doing string replacements, etc.), before putting together the final MSI package.