Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Version Snapshots
Hand-off from one person to the next occurs as a transition between work cycles. It is a good practice to take a version snapshot at the completion of a work cycle. This serves two purposes. First, it leaves an audit trail. Second, and perhaps more importantly, asset versioning provides the ability to isolate problems and to roll back to earlier versions of specific assets if needed.
There are common work cycles in web development. Figure 1 shows an overview of the four common work cycles in web development:
){kind=link}
Real-time development work cycle (edit-test work cycle)
Compare-update work cycle
Review cycle
Major test cycle
Figure 1 The four major work-cycles in web development.
Real-Time Development Work Cycle
Many web developers and content contributors spend the bulk of their time using their preferred content-creation tools, such as Photoshop, Dreamweaver, or Visual Studio. Figure 2 shows the web developer making edits in a workarea copy of a complete set of web assets. Using the browser this developer invokes the modified assets on the web server, renders the modified assets, and views the results in her browser. That's the direct feedback paradigm in action. The rest of the real-time development work cycle is spent saving the change and refreshing the browser. In contrast, a less effective work cycle without direct feedback might require the developer to FTP the files from her desktop machine to a web server before the changes could be viewed. This extra step slows down the cycle and reduces the developer's productivity. Indeed, even a minor interruption between the editing and the viewing is enough to break the developer's train of thought. Evidence suggests that even minor interruptions in a content developer's work cycle introduce major productivity losses that are disproportionate to the actual delay. Figure 2 shows the real-time development work cycle in action.
){kind=link}
Table 1 A Best-Practice Web-Development Process
Figure 2 In the real-time development cycle, a web developer edits and tests iteratively.
Compare-Update Work Cycle
In the compare-update phase, a developer compares the assets in his workarea to the corresponding assets in the staging area. The staging area contains updated assets that need to be periodically integrated into ongoing work, as other developers submit changes from other workareas. Figure 3 shows the compare-update work cycle.
){kind=link}
Figure 3 In the compare-update cycle, a developer resolves differences between his workarea and the staging area.
Review Work Cycle
Figure 4 shows the review work cycle, which involves two kinds of specialists: a reviewer and a content developer. Although we'll describe the case of a single reviewer and a single developer, it is clear that this work cycle can be extended to more than one of each kind of specialist. A content developer completes the real-time development work cycle and present modified assets for review. For example, an artist asks an art director to review images or proposed page layouts. A developer asks a peer to review changes made to programming source code. A template designer asks a business sponsor to review a common presentation template for all press release pages.
){kind=link}
Figure 4 The review cycle identifies more edits to be made.
The reviewer checks the assets in the context of a functioning web site. This adheres to the direct feedback principle for the reviewer and speeds the process. If the changes pass the review, the work cycle completes and the assets are ready to be submitted to the staging area. If the assets aren't acceptable, then the developer edits and retests, and the assets are reviewed again.
Major Test Work Cycle
Figure 5 shows the major test work cycle. A quality assurance (QA) engineer tests the assets in an edition. Following the direct-feedback principle, a web server renders the assets in the edition. If the testing proves successful, the edition is declared acceptable. If problems are discovered, defect reports are created and the respective developers are dispatched to resolve the problems. After review, changes are submitted to gather changes into the staging area. When appropriate, another edition is created and the major test work cycle continues. The need to cycle increases as a release deadline draws near. Just as separate workareas provide the ability for many developers to work in parallel, the major test work cycle accommodates many QA engineers working simultaneously.
){kind=link}
Figure 5 A QA engineer tests submitted content.