During every release, my stress level used to go up 10x. It shoudn't have to be that way. Here are my main deployment issues, with workaounds when applicable.
Did I change my config settings to reflect the production environment?
Not an easy one. Maintaining mutliple web.config files is a pain, so I'm using only one, with development, testing and production settings. I comment them out and uncomment each group of settings (appsetings, connection strings, assembly settings, email ...) depending on the environment. There's still room for user error, so if you have a better solution, please let me know.
I built all code libraries in Release mode, but did I forget to change the Web.Config compilation debug attribute to "false"?
Did I include all my license files?
You may have noticed that when publishing a web site in VS 2005, .lic and .licx files don't get copied automatically. This has been a real pain for months - for instance I kept forgetting to include my aspnetemail license; the site would seem to be running fine, but emails would consistently fail. Thankfully, there's a fix! Just edit your web.config compilation settings:
<add extension=".lic" type="System.Web.Compilation.ForceCopyBuildProvider">
This will force all *.lic files to be copied when publishing/precompiling your site.
Data and logic are out of sync on development and production machines. Some files are newer on the production server (images and docs uploaded by users for example), others are newer on my development machine (webforms, usercontrols, dlls, styles etc...)
Use virtual directories for all resources modified at runtime. This way, you don't have to worry about overwriting new data when deploying a new release.
Applying database changes
Versioning and deploying new code is easy, but what about your database? Personally, I keep a log of all database changes during development. The file is kept in SVN and can be modified by all developers. It looks like this:
- Created view_Catalog
- Updated spCatalogItem_GetDetails
Very simple. When we're ready to release, we move production data to the testing server, generate a sql file reflecting all the database changes tracked in the log, run the query on the testing database. If it's successful, we do the same on production.
If you're building a tiered application, you're probably writing unit tests as well. That's great, but how do you test the UI? If you're like me and can't afford a QA team, you're the one clicking all over your web app to make sure everything works properly. But every developer hates this, and has a tendency to only test things that are supposed to work.
One thing to consider is the atlas UpdatePanel. Partial page rendering can be turned on or off easily through the Script Manager; so in theroy you could turn it off, run your UI unit tests, then turn them on on production. This is just an idea though, I haven't tried it yet...
Also, I found this project in SourceForge. On paper, it looks interesting...
Link to NUnitWeb
Consider Web Deployment projects
Web Deployment Projects offer more build options, such as creating a virtual directory, replacing web.config sections, toggle debug compilation setting and more. See my next entry.
Web deployment projects resources:
Microsoft Web Deployment Project resource page
Web Application projects?
Microsoft recently released a template for this new project type. I haven't tried it yet, but apparently it's similar to web app projects in VS 2003. That's nice, it's a much cleaner approach when building an enterprise web application.
Microsoft Web Application Project resource page