Asp – Automatic Deployment to Multiple Production Environments

asp.netautomated-deploydeploymentweb-deployment

I want to update an ASP .NET web application (including web.config file changes and database scripts) to multiple production environments – ideally with the click of a button. I do not have direct network connectivity to any of them. I think this means the application servers will have to "pull" the information required for updating the application, and run a script to update the application that resides on the server.

Basically, I need a way to "publish" an update, and the servers see that update and automatically download and run it.

I've thought about possibly setting up an SFTP server for publishing updates, and developing a custom tool which is installed on production environments which looks at the SFTP server every day and downloads application files if they are available. That would at least get the required files onto the servers, and I could use xcopy/robocopy and Migrator.NET to deploy the updates. Still not sure about config file changes, but that at least gets me somewhere.

Is there any good solution for this scenario? Are there any tools that do this for you?

Best Answer

I think the pull rather than push strategy somewhat flaunts conventional wisdom... but this seems like something CruiseControl.NET could easily do. Remember the web.config file is also an XML document, so is easily modifiable in a CruiseControl script. You could xcopy files or use an svn export.

Related Solutions

.net – Managing complex Web.Config files between deployment environments

We split out all region specific settings into thier own config file. Under the root of the web app we create a config folder and place the region specific settings there. So whatever files are living under the root of config will get picked up.

our web.config looks something like:

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
    <MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
    <MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
    <MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

So if we are deploying to the release region the build tool will just have an action to replace the files in the root of config with the files from the appropriate region folder. The file structure looks something like:

ADDED: This is how the source control structure looks, the deployed app would just have the config dir with no sub folders or course

\Root
   web.config    
   \Config    
       appsettings.config    
       services.config    
       logging.config    
       \release    
          appsettings.config    
          services.config    
          logging.config    
       \debug
          appsettings.config    
          services.config    
          logging.config

It is pretty clean and supported by any automated build tool(copying/replacing files). The nice side effect is that developers can create different flavors and keep them under source control without affecting the "real" configs.

Differentiating web.config between dev, staging and production environments

My approach has been to have multiple config files. I put all environment agnostic stuff (i.e. doesn't matter if dev, staging, or production) in the web.config file. Anything that is specific to the environment (i.e. database connection info, logging, debug settings, etc.) I put into a local.config file specific to the environment. You can then include the local.config settings in the web.config using configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

Web.config can then be checked into source control. Don't check in the local.config files - that forces you to deploy the correct one in your deploy scripts.

Related Topic

Android – exec command android native code