After working with a hosted website for a little while it’s easy to come to the conclusion that deployment can be a real pain in the neck. Large 3rd party web hosts such as
Go Daddy (which is who hosts this site currently) certainly do not give you an easy way to migrate certain changes to your website. If your website is simple HTML and you’re doing some minor incremental changes from time to time then it’s not really a big deal but when it comes to a dynamic, datadrive website site, even one as simple as this one, deployment is painful.
The problem comes from not having direct access to the database. The database is securely hidden behind a firewall but as annoying as this is you wouldn’t really want it any other way. VPN access would be nice but it’s understandable why this isn’t available. As a solution they typically give you access to some web front end to your database and while this is better than nothing, frankly, these applications usually suck. I’ve found that not only are they usually pretty slow and visually confusing but they are typically not compatible with the same transactional scripts that you would run in your own development environment.
[Example of GoDaddy’s Web DB Frontend]
So this is the cruxt of the problem. The first time I went to deploy my site I had a rather long script full of table creates and primary keys and foreign keys and lengthy stored procedures only to attempt to run it in this web front end and have it fail miserably. I then removed the GO statements from my srcript, since it didn’t seem to like them, and I ended up with a spattering of tables and sprocs and had to go through and manually delete a lot of things. It was very painful and tiresome.
So after doing this about once you quickly realize there must be a better solution. The sample code posted with this blog is an example of how to make a reusable hosted website installation package. It’s pretty simple but that’s usually the best way to do things. You’ll probably want to refactor the code in this example to fit in with your project but here is the basic idea behind everything.
First off, you have your installer classes. You have an abstract InstallVersion class which is essentially a collection of InstallActions along with some version information. You will create one of these classes for each version you roll out to your server. It’s probably a good idea (and not much work) to keep all of your scripts and install version classes along the way rather than just upgrading the same one over and over. The reason for this is just in case you need to rebuild a database due to a migration, a crash or perhaps a new deployment without any of the old data. In those cases you may be stuck with nothing but ALTER TABLEs at the end and you’ll need to install everything from step 1 to 100 to get back to where you want to be.
Your first script will have mostly CREATE statments (probably from the complete.sql generated by NBusiness) but each subsequent one will have ALTERS as well as other things needed to massage your data into the new formats.
There are a couple of already made InstallActions created for running sql scripts but you can imagine all sorts of other actions such as ones that delete files, create/edit/delete Users and Roles if you’re using
ASP.NET Role/Membership providers. You could also imagine some actions that might do something like send an email to make sure you have your sites SMTP configurations setup correctly.
To configure your installer simply add a
custom install configuration section to your web.config. Check out the sample to see how to do this. Then you create a page in a secure directory (accessible only by admins) and add the Installer control to that page. The installer control will look at your configuration settings and load your install classes and ask them if they have been installed or not. If they have not then buttons will be created for that version, ready for you to execute the install actions. We’re using
NBusiness here to keep track of installed versions but you could just as easily come up with a scheme for saving files or something. Just remember that you don’t always have write permissions in medium trust like you do in your full trust development environement so always be sure to add the <trust level=”Medium” /> to your web.config so you can have a development environment with the same restrictions!
This is just one way to accomplish these goals. I’ve tried to add some semblance of a pattern and reuse to this problem and while this isn’t perfect (notably a lack of transactions across InstallActions) it’s MUCH better than nothing while still remaining pretty simple.
Enjoy!
You must be logged in to post a comment.