Need a copy/sync tool to deploy asp.net website

Question

I am trying to find a tool that will help us do our ASP.NET/IIS7 website deployment on to multiple machines.

We have a parallel production environment where we first deploy our software after the usual QA is done. This deployment is done via the provided msi (msi does not change the configurations). A deployment readme file is provided which instructs how to update configuration (if any). Once we feel that there are no hiccups in the new version, we copy the website to multiple (around 5 now, but might increase) production servers. The configuration files are not completely copied, but rather updated based on the changed settings and readme instructions.

Currently this copying process is done manually. I am looking for a tool that can do this copying for us without modifying any configuration files, so the operators can focus on only updating the config files.

Some interesting aspects of the issue

• All the files of interest are within a specific website root-folder. It contains multiple sub-folders, config files, dlls, exes, javascripts, and other asp.net files
• File-system on all the servers can be accessed in a read/write way using file shares
• The website root folder is not always at the same path across all servers
• Writing a simple copy has the problem that it will overwrite the config files too. We could not find an easy way to exclude the config files.
• The tool should backup the existing root-folder
• It would be great if the tool can also merge the web.config and similar xml configs - not sure if that is even possible.

The way I imagine the tool is that it will have some configuration file that will have an exclusion list (files not to copy) and another configuration to specify all the target folders where the copy job has to be repeated

Answer 1

The best way to do it is to use PowerShell script. With PowerShell script you have all the control to deploy a website onto several machines. Just use Copy-Item and select all files that you need. It can be done as a post-build event for example.

Answer 2

I've replied a similar question here. You could review Web Deploy which is the official Microsoft system to deploy to IIS and seems to fit your requirements.

Answer 3

We use a combination of Octopus and Jenkins to do our build and deploys. Jenkins builds the code and zips it up, storing it on Octopus. Octopus deploys it to various machines. We can choose which machines to deploy according to the channel - we first deploy to a single machine dedicated to staging and then if the stuff works we deploy to another 3 live machines using the exact same zipped code so we have confidence it will work the same

There is a bit of effort to set up this system but once it's done it pays off handsomely. The whole system is massively configurable and Octopus can carry out web config transformations so different machines can have different findings even though the code is the same

---

You might also consider an alternative that we use for some of our smaller sites - Kudu. It's a deployment and basic management system for IIS sites and in our case we have connected it to BitBucket source control (it can connect to other places like github or anywhere that will make a web request when code is pushed) so that pushing a change to a particular code branch like "production" will trigger a deployment. It's bitbucket that does the magic; the url to kudu is configured in BB, a push to any branch in the repo triggers a "this branch x has been updated" call to all connected Kudu and each Kudu knows the name of the branch it should listen to. In your case I imagine that kid have a staging branch that causes the first site to deploy and a production branch that causes the other 5 sites to deploy. Triggering a deployment by pushing to a branch is nice and easy for coders to get along with

In this latter system we manage differing configs on the various machines by environment variables;

• for our .net core apps we basically load "appsettings.json" then try to load "appsettings."+Environment.MachineName+".json" - common Settings go in the former, machine specific in the latter. Adding a new config for a new machine is a case of copying an existing one and adding it to the repo
• for non core apps we use an older system (which could have been used for core too) of a custom exe that is launched by a post build event, and it looks for a file called "web."+Environment.MachineName+".config" and copies it over the top of web.config. it's a simple (like 5 lines console app) way to do away with the headache of transforms - not all the team are a fan of them

Kudu is used on thousands of websites, many(mostly I'd say) hosted by Azure- the creator works for Microsoft and kudu is Azure's system of choice for deploying via CI. It also has helpful management stuff like running process lists and a command prompt emulator so you don't have to log in to the server to tweak stuff (because you can't log into an Azure web app service)