How to upgrade (merge) web.config with web deploy (msdeploy)?

Question

I'm trying to set up a deployment chain for some of our ASP.NET applications. The tool of choice is Web Deploy (msdeploy) - for now. Unfortunately I'm stuck on a problem.

A high level overview of the chain is thus:

1. Web developer creates the code and checks it in SVN;
2. Buildserver sees the update and builds the msdeploy .zip package of the website;
3. The .zip package is automatically put inside our installer and sent to various clients;
4. The clients run the installer on their webserver(-s);
5. The installer uses msdeploy internally to deploy the .zip package and create a new website or upgrade an existing one.

Msdeploy makes it easy to deploy a new instance, but I'm stumped about how to perform an "upgrade" install. The main problem is the web.config file. Each client will most certainly have made some customizations there to suit their specific environment. The installer itself offers to set some more critical parameters at the first-time installation (achieved by msdeploy's parameter mechanism), but they can do others by hand.

On the other hand, we developers also occasionally make changes to web.config, adding some new settings or removing obsolete ones. So I can't just tell msdeploy to ignore the file entirely. I need some kind of advanced XML modification mechanism. It could be a script that the developers maintain, but then it needs to be run ONLY at upgrades, not new installs.

I've no idea how to accomplish this.

Besides that, sometimes there's also some completely weird upgrade logic. For example, the application comes with our company logo, but some clients have replaced that .png file to show their own logo. Recently we needed to update the logo - but only for clients that hadn't replaced it with their own.

Similarly, there might be some cache folders that might need to be cleaned at SOME upgrades but not at others. Or folders with user content that may not be touched (but come with default content at the initial installation). Etc.

How do you normally achieve this dual behavior for msdeploy packages? Do I really need to create 2 distinct packages for every application?

Valid

Answer 1

Suggestion from personal experience:

Isolate customisations

Your customers should have the ability to customise their set up and the best way is to provide them with something like an override file. That way you install the new package and follow by superimposing your customer's customisations on top of your standard setup. If its a brand new install then there will be nothing to superimpose.

> top-level             --
    > standard files      |
           images         | This will never be touched or changed by customer
           settings.txt   |
                        __
    > customer files           --
           images                | Customer hacks this to their heart's content
           settings.txt_override |
                               --

Yes, this does mean that some kind of merging process needs to happen and there needs to be some script that does that but this approach has several advantages.

1. For settings that suddenly become redundant just issue a warning to that effect
2. If a customer has their own logo provide the ability to specify this in the override file
3. The message is clear to customers. Stay off standard files.
4. If customers request more customisable settings then write the default if it does not exist into the override file during upgrades.

Vilx, in answer to your question, the logic for knowing whether it is an upgrade or not must be contained in the script itself.

To run an upgrade script before installation

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat"

Or to run an upgrade script after installation

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat"

More info here

As to how you know its an upgrade your script could check for a text file called "version.txt" and if it exists the upgrade bat script will run. Version to be contained within the text file. Bit basic but it should work.

This also has the added advantage of giving you the ability of more elegantly merging customer's custom settings between versions as you know which properties could be overriden for that particular version.

Scammony

I do intend to move to this model, yes, but even THAT will need to be some kind of upgrade script. The problem is - how do I get upgrade scripts in msdeploy? I don't see how I could make it run a script if and only if it's an upgrade. – Valid

+1 for isolating customizations, that's a very clean way to handle things. You could even take it a step further than described here: instead of placing your customer files below the top-level installation folder, you could place them outside and have only a config setting (which the customer can specify in the parameters file during installation/upgrade) for this location. Checking "if and only if it's an upgrade" will then be as simple as checking if this folder exists (or e.g. if a version.txt exists inside this folder). And your pre/post script can process these files as necessary. – Lanell

Answer 2

There are some general suggestions (not specific to msdeploy), but I hope that helps:

• I think you'll need to provide several installers anyway: for the initial setup and for each version-to-version upgrade.

• I would suggest to let your clients to merge the config files themselves. You could just provide them either detailed desciption of waht was added/changed/removed, and/or include the utility that simplifies the merge. Maybe this and this links will give you some pointers.

• as for merging the replaced logos, other client's customization, I think the best approach would be to support branding your application. I mean - move all branding details to the place where your new/upgrade installers won't touch that.

• as for the rest of the adjustments made by your clients, they do that on their own risk, so the only help you could provide them is to include the detailed list of changes (maybe even the list of changed files since the previous version) and the How-To article about merging the sources with tools like Araxis Merge or similar

• Or.. you could create a utility and include it to the installer, which will try to do all the tricky merging stuff on client's machine. I would not recommend this way as it requires a lot of efforts/resources to maintain.

• One more thing: you could focus on backup-ing the previous client copy before upgrade. So even client will have troubles with upgrading - that will be always possible to roll back. The only thing here for you is to provide a good feedback channel which your clients can use to shoot their troubles. This feedback will allow you to figure out what the troubles your clients have and how to make their upgrade process more comfortable.

Overtake

Answer 3

I would build on what the above have said, but I would do it with transformations, and strict documentation about who configures what. The way you have it now relies on customer intervention against a config that is mission critical to the app deploy process.

Create three config file areas. One for development, one for the "production generic" build, and one that is an empty template for the customer to edit.

• The development instance should be self explanatory. This is the transform that takes the production generic template and creates a web config for your development server. (it sounds like you are shooting for a CI type process here)
• The "production generic" transform should set the app up for a hypothetically perfect instance of the app. This is what the install would look like if the architect had his way.
• The customer transform is used by the customers to set up the web config as required to meet their own needs. Write some documentation and see what happens. Edit the docs as you help customers through the process.

It that what you were looking for? Thoughts?

Druci