What method do you use to deploy ASP.Net applications to the wild?

Question

Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.

I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).

Secondly, I'm looking at merging deployments and automatic updates.

How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?

Answer 1

Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.

Answer 2

A couple things that I have done is the following:

1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments. 2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.

The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.

Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.

Hope this helps.

Answer 3

We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.

Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'. To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.

In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.

Answer 4

1) Build project with MSBUILD

2) FTP files to Production Environment

3) Copy / Paste manually to each web server

Answer 5

For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.

Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.

Answer 6

We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.

We also have a dedicated build machine which runs Cruise Control.

Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.

To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.

To deploy to QA, the files are copied from the development machines to the QA machines.

Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.

Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.

To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.

So each environment can be deployed with a button push from the Cruise Control dashboard.

One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!

Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.

Let me know if this helps, or if you have any questions.

Thanks!