CTA Logo
What We Do

CTA Development › Topics

 

CTA Engineering

Services

Topics

Case Studies

CTA Development

Services

Topics

Solution Profiles

WaveCS Services

GSA Information

Labor Rates

Labor Categories

 

 

8 Tips for Simplifying Web Application Deployment

A big reason we choose web technology is to simplify the deployment process. Let that simplification work for you. Here is a list of items to consider when building and deploying your next web application. Some of these best practices are specifically illustrated using ASP or ASP.NET, but nearly all of these make sense no matter what development tool you use.

  1. Never reference physical paths within your code. For instance, using c:\inetpub\wwwroot\myapp\myconfiguration.xml would be a bad thing. Use server.mappath to extract the virtual directory's physical path from the web server.

  2. Try to avoid absolute web paths within your code. If you're adding an href to an anchor tag, it's much better to use href = "./images/mypicture.jpg", rather than href = "/MyApp/images/mypicture". This applies to all page references within your application that you may use, such as response.redirect and server.execute. If you must store the virtual directory name within the application, consider putting it in a configuration file (web.config), an include file, or even a configuration table within a database. Whatever method you choose, store it one time and reference that repeatedly. Avoid using the http:// URL prefix, if at all possible. Consider the consequences if you are suddenly required to use https.

  3. Identical database connection strings should only be stored one time. Place these within an include file or web.config.

  4. After the application is deployed, try to avoid changing the virtual directory name or the initial startup page. This can cause numerous problems. Say your initial startup page is NewStartup.asp, and you've renamed it NewStartup2.asp. What happens to all the shortcuts or other references to your initial page? What about any bookmarks users might have from the previous version? Yup, they're broken. There's no easy way to fix this, without having to hack in new code just for redirection.

  5. Any version of an application which you deploy should be version stamped and burned to CD. I like to make two copies. One goes to the customer and the other goes to my file cabinet. This CD should be a direct match to what's in your source code repository.

  6. When you update your application, keep in mind what rollback contingencies you've given yourself. Any update should be quick and easy to rollback.

  7. If local disk space permits, make an online backup of the application's database. Do this even if you're not modifying any database objects or data.

  8. When you update the production instance of the application, try to avoid updating just a page or two. Instead, copy the whole application portion of the CD to the root of the production site. Try to keep an online backup of the original to speed up the rollback process. Some people like to keep multiple backups-I don't have any problems with this, but keep it to a minimum. Most rollbacks occur within 2 to 3 days of deployment, so there's no need to store multiple copies which are months old. Hopefully, you've burned to CD, so you could reference that older code base, if necessary.

Here are some specific steps which you can follow for application updates:

  1. Backup all data. Include the date in the filename of the database backup and put in an appropriate backup folder.

  2. Backup all code. Here's an easy way to approach this. Rename the application folder and label the folder with the application version or date. For instance, if the current application folder is MyApp, rename it to MyAppv1-5 or MyApp07-20-02. Create a new folder with the same name as before (i.e. MyApp)--this will ensure the virtual directory doesn't need to be changed. Don't label this new folder with the version or the date.

  3. If a rollback is required, all you do is change the web server's virtual directory to point to the backup folder and restore any databases, if necessary. This shouldn't take more that a few minutes. Correct the folder names on the next deployment