How do you deploy your ASP.NET applications to liv

Question

I am looking for different techniques/tools you use to deploy an ASP.NET web application project (NOT ASP.NET web site) to production?

I am particularly interested of the workflow happening between the time your Continuous Integration Build server drops the binaries at some location and the time the first user request hits these binaries.

1. Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?

2. When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?

3. When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?

4. Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?

Feel free to complete the previous list.

---

And here's what we use to deploy our ASP.NET applications:

1. We add a Web Deployment Project to the solution and set it up to build the ASP.NET web application
2. We add a Setup Project (NOT Web Setup Project) to the solution and set it to take the output of the Web Deployment Project
3. We add a custom install action and in the OnInstall event we run a custom build .NET assembly that creates an App Pool and a Virtual Directory in IIS using System.DirectoryServices.DirectoryEntry (This task is performed only the first time an application is deployed). We support multiple Web Sites in IIS, Authentication for Virtual Directories and setting identities for App Pools.
4. We add a custom task in TFS to build the Setup Project (TFS does not support Setup Projects so we had to use devenv.exe to build the MSI)
5. The MSI is installed on the live server (if there's a previous version of the MSI it is first uninstalled)

Answer 1

At the last company I worked for we used to deploy using an rSync batch file to upload only the changes since the last upload. The beauty of rSync is that you can add exclude lists to exclude specific files or filename patterns. So excluding all of our .cs files, solution and project files is really easy, for instance.

We were using TortoiseSVN for version control, and so it was nice to be able to write in several SVN commands to accomplish the following:

• First off, check the user has the latest revision. If not, either prompt them to update or run the update right there and then.
• Download a text file from the server called "synclog.txt" that details who the SVN user is, what revision number they are uploading and the date and time of the upload. Append a new line for the current upload and then send it back to the server along with the changed files. This makes it extremely easy to find out what version of the site to roll back to on the off chance that an upload causes problems.

In addition to this there is a second batch file that just checks for file differences on the live server. This can highlight the common problem where someone would upload but not commit their changes to SVN. Combined with the sync log mentioned above we could find out who the likely culprit was and ask them to commit their work.

And lastly, rSync allows you to take a backup of the files that were replaced during the upload. We had it move them into a backup folder So if you suddenly realised that some of the files should not have been overwritten, you can find the last backup up version of every file in that folder.

While the solution felt a little clunky at the time I have since come to appreciate it a whole lot more when working in environments where the upload method is a lot less elegant or easy (remote desktop, copy and paste the entire site, for instance).

Answer 2

I'd recommend NOT just overwriting existing application files but instead create a directory per version and repointing the IIS application to the new path. This has several benefits:

• Quick to revert if needed
• No need to stop IIS or the app pool to avoid locking issues
• No risk of old files causing problems
• More or less zero downtime (usually just a pause at the new appdomain initialises)

The only issue we've had is resources being cached if you don't restart the app pool and rely on the automatic appdomain switch.

Answer 3

Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?

As a developer for BuildMaster, this is naturally what I use. All applications are built and packaged within the tool as artifacts, which are stored internally as ZIP files.

When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?

Manually - we create a change control within the tool that reminds us the exact steps to perform in future environments as the application moves through its testing environments. This could also be automated with a simple PowerShell script, but we do not add new applications very often so it's just as easy to spend the 1 minute it takes to create the site manually.

When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?

By default, the process of deploying artifacts is set-up such that only files that are modified are transferred to the target server - this includes everything from CSS files, JavaScript files, ASPX pages, and linked assemblies.

Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?

Yes, BuildMaster handles all of this for us. Restoring is mostly as simple as re-executing an old build promotion, but sometimes database changes need to be manually restored, and data loss can occur. The basic rollback process is detailed here: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Answer 4

Website

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

I publish website to a local folder, zip it, then upload it over FTP. Deployer on server then extracts zip, replaces config values (in Web.Config and other files), and that's it.

Of course for first run you need to connect to the server and setup IIS WebSite, database, but after that publishing updates is piece of cake.

Database

For keeping databases in sync I use http://www.red-gate.com/products/sql-development/sql-compare/

If server is behind bunch of routers and you can't directly connect (which is requirement of SQL Compare), use https://secure.logmein.com/products/hamachi2/ to create VPN.

Answer 5

Unfold is a capistrano-like deployment solution I wrote for .net applications. It is what we use on all of our projects and it's a very flexible solution. It solves most of the typical problems for .net applications as explained in this blog post by Rob Conery.

• it comes with a good "default" behavior, in the sense that it does a lot of standard stuff for you: getting the code from source control, building, creating the application pool, setting up IIS, etc
• releases based on what's in source control
• it has task hooks, so the default behaviour can be easily extended or altered
• it has rollback
• it's all powershell, so there aren't any external dependencies
• it uses powershell remoting to access remote machines

Here's an introduction and some other blog posts.

So to answer the questions above:

• How is the application packaged (ZIP, MSI, ...)?

  Git (or another scm) is the default way to get the application on the target machine. Alternatively you can perform a local build and copy the result over the Powereshell remoting connection

• When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?

  Unfold configures the application pool and website application using Powershell's WebAdministration Module. It allows us (and you) to modify any aspect of the application pool or website

• When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?

  Yes unfold does this, any deploy is installed next to the others. That way we can easily rollback when somehting goes wrong. It also allows us to easily trace back a deployed version to a source control revision.

• Do you keep track of all deployed versions for a given application?

  Yes, unfold keeps old versions around. Not all versions, but a number of versions. It makes rolling back almost trivial.

Answer 6

We do rolling deployment to the live servers, so we don't use installer projects; we have something more like CI:

• "live" build-server builds from the approved source (not the "HEAD" of the repo)
• (after it has taken a backup ;-p)
• robocopy publishes to a staging server ("live", but not in the F5 cluster)
• final validation done on the staging server, often with "hosts" hacks to emulate the entire thing as closely as possible
• robocopy /L is used automatically to distribute a list of the changes in the next "push", to alert of any goofs
• as part of a scheduled process, the cluster is cycled, deploying to the nodes in the cluster via robocopy (while they are out of the cluster)

robocopy automatically ensures that only changes are deployed.

Re the App Pool etc; I would love this to be automated (see this question), but at the moment it is manual. I really want to change that, though.

(it probably helps that we have our own data-centre and server-farm "on-site", so we don't have to cross many hurdles)