Deploying the application
Deploying the application
When you are finished developing an RIA, you need to deploy it so users of the application can access it. Flash applications can run in a variety of contexts, such as desktop applications or touchscreen kiosks. However, the most common deployment mechanism for Flash applications—and the one I focus on here—is running in a web browser.
Embed Flash in HTML
Configuration parameters to Flash: You can send static, fixed parameters from HTML to Flash to configure an application. For example, we can configure RbkCustom using a parameter set in HTML to show a warning dialog box every time it encounters an erroneous recipe:
<param name="flashVars" value="showRecipeErrors=false">
These query string parameters cause RbkCustom to open a lovely orange, white, brown, and yellow Supercourt shoe (see Figure 2).
Figure 2. Supercourt shoe customized by query string parameters
Eolas patent: The Microsoft Internet Explorer browser was changed in early 2006 to require end users to explicitly click ActiveX controls in order to activate them. This effectively put a speed bump in front of Flash applications. Fortunately, there is an easy workaround: the
Test, test, and test
To increase the chances of deploying the software smoothly, your development team must test it several ways. The earlier you identify bugs, the more easily you can fix them. For this reason, we emphasize rigorous unit testing by our individual developers to ensure that each individual piece of code behaves as it should.
When functional subsystems of the application are complete, somebody unfamiliar with the application proceeds with testing. Developers know the system too well and often overlook basic problems. We use the open-source Bugzilla bug-tracking system to ensure that the bugs we find are fixed in a timely manner.
To test the performance of some critical systems, we establish minimum guidelines in the technical specification and then conduct performance testing to ensure that we have met those requirements.
Tame the server environments
We usually have two server environments for our projects, one for production deployment and one for development and testing. We make these environments as similar as possible: same number of servers, same hardware, same operating systems, and same software. The similarity of our testing platform gives us increased confidence that our production deployments will be smooth.
RbkCustom has two servers in each environment: a database server and a second, physical server computer that runs both the web server and application server software. Our production environment is hosted by VeriCenter and runs on leased servers. We operate the development environment ourselves. After investing a couple of days in the initial setup, our resident IT wizard spends a couple of hours each month maintaining the development environment.
Maintain version control
We manage all of our code using a version control system that helps us coordinate the work of multiple developers throughout the development process. Version control also helps us deploy our projects into production in a controlled manner.
Prior to deploying the project, we create a tag in the version control system that identifies the specific versions of all the files that are involved in the production deployment. This tag includes all the source code (ActionScript code and FLAs) required to regenerate the deployed SWFs. We only deploy tagged SWFs into production.
For RbkCustom, we have one set of tags for the consumer-facing Configurator application, a second set for the Administrative Tools application, and a third set for the Java application server code that supports them. The Configurator tags have the structure RBKCUSTOM_CONFIGURATOR_1_2_3. The first digit is the major version number, the second is the minor version number, and the third is the subversion number. Similarly the Administrative Tools tags are named in the pattern RBKCUSTOM_ADMINTOOLS_1_2_3, and the server code is tagged with names like RBKCUSTOM_SERVER_1_2_3.
This tagging serves two purposes. If a subsequent deployment causes problems, we can easily revert to the prior version using the prior tag. Sometimes we need to fix a deployed version after subsequent development has occurred that cannot be put into production. In this circumstance, we copy the source code that was used to generate the problematic production build, make changes to that code, and then compile new SWFs for immediate use in production.
A few rules of thumb can help you develop rich Internet applications effectively. Prepare yourself by thoroughly understanding the applications you are building. Creating specification documents and diagrams helps you systematically research your applications and share your knowledge with prospective end users and other team members.
Writing consistently formatted, well-documented, and well-structured code makes it easier for you to work with the code, and improves the support provided by compilers and editors. We minimize the amount of code we write by reusing existing code. This reuse improves both the efficiency of development and the quality of the code.
Flash presents unique development challenges because the binary FLA file format is difficult to share among developers. Two handy rules assist us in working with FLA files: engineers never edit FLAs, and we have at least one FLA per concurrent designer working on the project.