部署 ASP.Net Web 应用程序的好方法是什么？

Question

We currently deploy web applications by creating a database and running SQL scripts through query analyzer. Then we copy the output from "publish website" and set up that website in IIS.

We have seen websetup in visual studio, but that part seems to be thinly documented. For example, we are not clear how to ask the user for IP and password of SQL server. We also tend to get websites deployed this way coming up under folders like http://example.com/project , instead of just http://example.com .

Then there are issues with AJAX.Net not being installed or some or the other patch not applied.

So far, we have physical access to the servers. Pretty soon though we are going to be shipping CDROMs. What is the practical tradeoff between manual intervention and automation?

Answer 1

Avoid Visual Studio deployment, and automate as much as possible. Web Deployment Projects and NAnt can be your friends!

Briefly, our deployment setup:

1. We use RedGate SQL to script differences between dev and live database.

2. An NAnt build file which calls MSBUILD to build the web deployment project (.wdproj), zips up the resulting compiled web app (along with the SQL change script) and then uploads the zip file to the server.

3. On the server side, there is another NAnt build file which takes the application offline, backs up the database, backs up the website. runs the SQL change script, unzips the new version and brings the app online.

Step 3 is usually run "manually" (one double-click), but sometimes scheduled for late at night. You could do exactly the same from a CDROM, or even write a pretty little Windows Forms app as a wrapper.

Quite happy to give details of the NAnt script if you're interested.

Answer 2

Have you tried using Web Deployment project? There is support for VS 2008 also now..

Answer 3

I deploy mostly ASP.NET apps to Linux servers. 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/