Releasing a Web Application

The purpose of this wiki entry is to take notes on what considerations need to be made when packaging and releasing a web application. I have no experience releasing software, so this page will combine intuition with my observations. A few of the points I'll cover include:

1. When is a web application ready to be released?
2. Defining the feature set of a release
3. Usability of the install package

Let's start with a question to counter the first:
Do the primary features of the application work, and are they bug free?

Most software is not bug-free, simply because it's near impossible to test a piece of software in every possible state. However, it's inexcusable to have a bug that exists in a primary feature. Such features are critcal to the release of an application, and bugs in critical features hint that an application is not ready for release.

It wouldn't be good to release a paint program that errored out upon selecting the paintbrush tool. Without a usable paintbrush tool, the program is not usable, and so a paintbrush application should not be released until all paintbrush bugs have been resolved.

Perhaps the paintbrush program has a spraypaint feature that errors out if the mouse drags too fast across the screen. This would only be important to those that will use the spraypaint feature. If the spraypaint feature is a more of a marketing thing, and won't be used by the majority of the user/customer base, it might be worth releasing the feature in a later version.



Defining the features for a release is critical to getting the product "out the door".

Without a defined feature set, there is no project timeline, and the release date could get pushed back every time a developer/engineer comes up with a new bell or whistle. Defining and obeying the proposed feature set for a release should ensure that the given application is not in a state of perpetual beta. Any engineer knows that nothing is more painful than starting the same project three times due to an evolving feature set...

The feature set should also include the conditions under which the software can operate. In other words, if your web application has not been tested in multiple browsers, browsers that have not been tested should not be included in the feature set.

For web applications, software support should consider the destination of the install package: the OS, web server, database management software, and programming language. A specific example of these elements is commonly recognized as a LAMP software bundle, which utilizes Linux, Apache, MySQL, and PHP.



Defining usability largely depends on the target audience. There was a time where those who installed web applications on servers were generally computer savvy. These days, everyone and their mother has a weblog. An automated package that self-configures the application might be prefered by a journalist, while a software developer would probably prefer to manually configure the app during installation.



Lately I've been reading Alex King's weblog. On a recent blog post he noted: "lots of little upgrades are much better than an occasional mammoth upgrade. Showing your users that your product is alive and well and growing is important".