Installing/Updating a web site
I’ve been wondering lately about best practices for installing and updating an asp.net web site (or any web site, for that matter). Suppose I have a web site that I’ve been working on, and I’m now ready to deploy it to the production server for the first time. I can create a setup project in VS that will bundle all my files together, install the database, do any custom actions I want, and create an .msi file to install my web app for the first time.
Thats all well and good until the site has been running for awhile and you’ve been fixing bugs, now you want to roll out an update of the web site, which would include, for instance, changes to the assemblies, changes to some of the .aspx files, and some database changes as well. Whats the best way to roll these changes out? I would like to make another installer that detects what needs to be installed, and only installs the updated bits and updates the database, but I also want the new installer to be able to install the entire updated site if I was installing it on a clean server. What I don’t want, is something that uninstalls the current site, and then reinstalls the entire thing. Does this functionality exist out of the box with .net setup projects? Or is this something I would have to create on my own? Or am I missing a better way to deploy updates to web sites? So many questions……….
Underwhelmed said,
Wrote on February 8, 2006 @ 4:11 pm
For my websites, I use AllwaySync. It lets you know which files have been changed and allows you to only copy the files you want (filters). If it’s a hosted website and has an FTP, I use this program in conjunction with Novell NetDrive.
For the SQL, I use RedGate SQL Compare. It will create an upgrade script as well.
If you’re deploying this for someone else to make changes, then I’m not sure because I haven’t gone down this avenue.
Anonymous said,
Wrote on February 8, 2006 @ 4:53 pm
The only thing we use is this software http://www.sqlmanager.net/en/products/mssql/dbcomparer for the database
as for updating the program itself, why is that a problem?
breichelt said,
Wrote on February 9, 2006 @ 9:48 am
Underwhelmed, thats not a bad solution for when I’m updating the site myself, but I was referring to someone else being able to make the change in the easiest way possible.
Thomas, I dont think I understand your question. Updating the program (the website) can be a problem because I want to update only specific pieces, not the entire site. This isn’t an issue with smaller sites, but with a big site that spans many virtual directories, etc, it can be an issue.
Anonymous said,
Wrote on February 9, 2006 @ 5:38 pm
First, I use RedGate SQLCompare to compare my dev and live databases, so see if there are any schema changes to move across. SQLCompare is pretty cheap, and you can use it from the command line to do this automatically if you’re brave.
To do the publishing, I use NAnt, which has a task to copy files from a source directory to destination directory, only copying files that are newer in the source. This handles the “what should be updated” part of it. With a nant you can script out what directories in your source tree should be copied where, so having tons of virtual directories shouldn’t be a problem.
NAnt also has some tasks to create IIS virtual directories, which can take care of the initial installation steps of a website, and prove useful should you need to move the site elsewhere.
The setup works pretty nicely for me.
jkimble said,
Wrote on February 10, 2006 @ 10:16 am
I think you already had some ideas for SQL…
In ASP.Net 1.1, I would set up each sub directory as it’s own project with the main root dir/project inheriting all the others. Then I could simply redeploy just the one sub directory’s (or a couple subdirs) aspx files and put all the DLLs for that project into the bin folder into the root folder’s bin subdirectory.
It’s not perfect, but it worked fairly well for my efforts.