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

Answering your questions:

1. XCopy
2. Manually
3. For static resources, we only deploy the changed resource.
   For DLL's we deploy the changed DLL and ASPX pages.
4. Yes, and yes.

Keeping it nice and simple has saved us alot of headaches so far.

Answer 2

I deploy mostly ASP.NET apps to Linux servers and redeploy everything for even the smallest change. Here is my standard workflow:

• I use a source code repository (like Subversion)
• On the server, I have a bash script that does the following:
  • Checks out the latest code
  • Does a build (creates the DLLs)
  • Filters the files down to the essentials (removes code files for example)
  • Backs up the database
  • Deploys the files to the web server in a directory named with the current date
  • Updates the database if a new schema is included in the deployment
  • Makes the new installation the default one so it will be served with the next hit

Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.

On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.

In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.

Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.

It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.

I really need to update the copy of ReleaseIt on CodePlex sometime:

http://releaseit.codeplex.com/

Answer 3

web setup/install projects - so you can easily uninstall it if something goes wrong

Answer 4

We have all of our code deployed in MSIs using Setup Factory. If something has to change we redeploy the entire solution. This sounds like overkill for a css file, but it absolutely keeps all environments in sync, and we know exactly what is in production (we deploy to all test and uat environments the same way).

Answer 5

Back in 2009, where this answer hails from, we used CruiseControl.net for our Continuous Integration builds, which also outputted Release Media.

From there we used Smart Sync software to compare against a production server that was out of the load balanced pool, and moved the changes up.

Finally, after validating the release, we ran a DOS script that primarily used RoboCopy to sync the code over to the live servers, stopping/starting IIS as it went.

Answer 6

We've been improving our release process for the past year and now we've got it down pat. I'm using Jenkins to manage all of our automated builds and releases, but I'm sure you could use TeamCity or CruiseControl.

So upon checkin, our "normal" build does the following:

• Jenkins does a SVN update to fetch the latest version of the code
• A NuGet package restore is done running against our own local NuGet repository
• The application is compiled using MsBuild. Setting this up is an adventure, because you need to install the correct MsBuild and then the ASP.NET and MVC dll's on your build box. (As a side note, when I had <MvcBuildViews>true</MvcBuildViews> entered in my .csproj files to compile the views, msbuild was randomly crashing, so I had to disable it)
• Once the code is compiled the unit tests are run (I'm using nunit for this, but you can use anything you want)
• If all the unit tests pass, I stop the IIS app pool, deploy the app locally (just a few basic XCOPY commands to copy over the necessary files) and then restart IIS (I've had problems with IIS locking files, and this solved it)
• I have separate web.config files for each environment; dev, uat, prod. (I tried using the web transformation stuff with little success). So the right web.config file is also copied across
• I then use PhantomJS to execute a bunch of UI tests. It also takes a bunch of screenshots at different resolutions (mobile, desktop) and stamps each screenshot with some information (page title, resolution). Jenkins has great support for handling these screenshots and they are saved as part of the build
• Once the integration UI tests pass the build is successful

If someone clicks "Deploy to UAT":

• If the last build was successful, Jenkins does another SVN update
• The application is compiled using a RELEASE configuration
• A "www" directory is created and the application is copied into it
• I then use winscp to synchronise the filesystem between the build box and UAT
• I send a HTTP request to the UAT server and make sure I get back a 200
• This revision is tagged in SVN as UAT-datetime
• If we've got this far, build is successful!

When we click "Deploy to Prod":

• The user selects a UAT Tag that was previously created
• The tag is "switched" to
• Code is compiled and synced with Prod server
• Http request to Prod server
• This revision is tagged in SVN as Prod-datetime
• The release is zipped and stored

All up a full build to production takes about 30 secs which I'm very, very happy with.

Upsides to this solution:

• It's fast
• Unit tests should catch logic errors
• When a UI bug gets into production, the screenshots will hopefully show what revision # caused the it
• UAT and Prod are kept in sync
• Jenkins shows you a great release history to UAT and Prod with all of the commit messages
• UAT and Prod releases are all tagged automatically
• You can see when releases happen and who did them

The main downsides to this solution are:

• Whenever you do a release to Prod you need to do a release to UAT. This was a conscious decision we made because we wanted to always ensure that UAT is always up to date with Prod. Still, it's a pain.
• There's quite a few configuration files floating around. I've attempted to have it all in Jenkins, but there's a few support batch files needed as part of the process. (These are also checked in).
• DB upgrade and downgrade scripts are part of the app and run at app startup. It works (mostly), but it's a pain.

I'd love to hear any other possible improvements!