How do you deploy and manage a C# web application to a customer with some minor differences from your base project?

Question

I have a semi-large web application that we run locally and I need to deploy it at another location. The second location will require some slight modifications to the project (especially cosmetic). How do you manage these differences and what do you use to distribute the site and updates to a customer like this?

Edit: Right now our web app runs in-house and we build with Cruise Control .NET and MSBuild with WDP. What would be a good option for deployment to the customer? We will not be updating their site for them so a solution that is simple for them to deploy and update is desirable.

Answer 1

Custom patches are a pain for this very reason. We typically just branch in our source control system, and manually apply the changes after updating with a script. Because of the additional overhead, we discourage custom patches as much as possible.

Answer 2

Branch your code.

Hopefully your code is source controlled (if not, start now!), you should branch from the base to the "Customer X" branch and just make the slight cosmetic modifications in that branch. Then just build and deploy off of that branch for that customer.

Additionally, if the changes are minor enough, you could try to make the changes configurable. That way you could deploy the same site everywhere, and just change the configuration to match what the customer wants. The more complex the differences, the harder it will be to make them configurable though.

After reviewing comments: Its good to note that configuration is practical, but ONLY if the # of changes are minor, otherwise you will pollute your code with configuration logic. (Thanks commenters)

So: Lots of changes --> Branch (more maintainable), few minor changes --> Make configurable (more practical).

Answer 3

We usually make those differences by being data driven. The customer's difference is just a different setting; any other user in the future could as well reuse the same "custom" options later on.

Creating "one-off"s doesn't scale.

Answer 4

We have to do it all the time. We try to generalize and make the differences between versions configurable. The most common reasons for customizations are:

• additional database fields: we implemented a dynamic way to store these items in db
• UI layout: we have special folders where we put images and css files which are loaded on demand
• different mandatory input fields: we store the definition in the configuration and activate them programmatically
• special reports: we put the template files in the custom folder in order to be chosen instead of the standard template

Some changes require programming new modules. We code them in a custom library which will be dynamically loaded inside the main application.