15

So, not sure if this is a Stack Overflow or a Server Fault question. If I have a .NET website that I want to deploy to the production environment, what's the best way to do so. Should I package it as an MSI & install? Use nant to push the needed files up. Just FTP the files up using Beyond Compare?

How do you deploy production code? This is a Windows specific case that I'm looking at here.

Improve this question

5 Answers 5

Reset to default
15

IIS supports xcopy deployment so just copying the files should be all you need unless you have special requirements.

One way to do it is a simple script that uses ROBOCOPY to copy the new files to the server.

If the site is large and this takes too long, use a version control system. I like Mercurial for this purpose, although you have to be careful that the version control system's configuration files don't end up being served to the public. Deploying is then simply a matter of committing the changes and then checking out the latest version on the server. In addition to being efficient, this allows quick rollbacks (if you tagged the last good version) in case your latest-and-greatest has a showstopper bug.

To minimize downtime, you could have the script copy the files to a new directory and then quickly rename the directories, or change where IIS points to the new directory.

Improve this answer
3
  • 1
    The version control system is appealing but for web sites that require compilation it might not work out too well. Unless a compiled version is kept under version control of course.
    – Jonathon Watney
    May 1, 2009 at 3:20
  • 1
    I never thought of putting a source control system out in production. Interesting sure beats having to keep tons of extra zip files around.
    – JoshBerke
    May 1, 2009 at 4:23
  • I do this all the time with Subversion. On Apache you'd use mod_rewrite to make sure users can't access the .svn directories. Using version control for deployment is definitely the way to go.
    – Luke
    May 4, 2009 at 7:07
13

Consider using the Web Deployment Tool from Microsoft. It was specifically designed to help deploy web applications and updates to those web applications to production IIS 6 and 7 web servers and it does a better job of the task than MSI (Windows Installer), IMHO.

Normally you use it by setting up a "gold master" site somewhere and then telling the tool to pack up the changes from there. It will then look at a target server for deployment and make any changes necessary to make it look like the gold master (which is useful for subsequent updates). It is particularly useful if you are deploying to more than one web server (i.e. a farm), and it has support for deploying more than just files (it can also handle making registry changes, deploying certs, SQL databases, etc).

Improve this answer
1
  • +infinity. This tool is a lifesaver and frees entire departments (a la tsilb) to work on more interesting problems.
    – Portman
    May 4, 2009 at 1:33
4

I'd further Joel's answer by suggesting a Continuous Integration server pickup your changes from your source control system. It will then build the project. Then have it xcopy the output of the build to a new folder. You can then do some quick config changes (web.config and app.config). Voila, ready for Xcopy!

Check out CruiseControl.NET

Improve this answer
3

What I did at my previous employer, which was basically an auction/e-commerce site where we could not permit much downtime:

  • Take a zipped build version of the release/version to deploy on the build server
  • Test it on a staging server which has a copy of the production database and has the same version of software as the production software. Test that everything went smoothly. If not restart the deployment of the staging server (but first restore a backup).
  • If everything went well: copy build and database upgrade scripts to production server to a local folder. Take a specific backup of the database and the ASP.NET files (in case something still goes wrong). Prepare then everything so that I only have to click enter to launch the upgrade script and the copying of the database files (note that I could a create a script for this). Then launch everything. This is normally a matter of seconds and the users won't notice much that there has been downtime.

There a lot of funnier things to do as a web developer. But this was the most crucial part of my work.

Improve this answer
1

oh jeeez, at work we have a whole team for this. They have an in-house tool that takes a server out of the cluster/farm, publishes the files, runs the NUnits, and adds it back into the cluster/farm. They do this for each of 16 servers. It takes hours. The rest of us don't even have "look around access".

For my personal projects, I publish from VS2005 directly to my webserver. Kinda has less strict security.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .