31.2 Example Scenario

The Web team consists of a content development team in Massachusetts and a publishing team in California. The Web server for the external Web site is in California.

The Web team follows this publishing cycle:

1. Developers change the source files.

2. Development team leaders approve the changes.

3. Approved changes are tested in Massachusetts.

4. Changes are sent to California.

5. The publishing team runs a final test on the new content.

6. New content is published.

The team leaders at both sites established these policies:

• All source files must be tested for correctness of links, style, and colors, and the presence of ALT tags for images before developers can submit them for approval.

• Only the team leaders can approve changes for publishing.

The following sections describe how each team uses ClearCase to control the publishing cycle and enforce policies.

VOB and Branch Configuration

All source files (.HTML, .PDF, .GIF, and .DOC) are stored in ClearCase VOBs. The Web team uses branches to separate ongoing development work from the work approved for publication. The development team uses the devweb branch. Approved changes are merged to the main branch, and the Web site is published from the latest versions on the main branch. Figure 42 shows a version tree, including merges, for an element.

Figure 42 Development and Publishing Branches

Because the development team works at a different site, the VOB that stores Web content is replicated. The developers work in the mass VOB replica, and the publishing team publishes files from the calif replica. Because no development is done in California, synchronization of the replicas is unidirectional (changes are sent from mass to calif). The Web server is located outside the firewall, so the publishing team uses custom scripts to copy the content from the VOB to the external Web server.

Figure 43 VOB and Web Server Configuration

If development were also done in California, each site would have a site-specific branch (for example, devweb_ma and devweb_ca), and changes would be merged to the main branch at one site. Synchronization of the replica would occur in both directions, and depending on the speed of development, synchronization might be as frequent as four times an hour.

View Configuration for Tasks

By displaying the Web content in different views, the webmaster can use versioning and branching to control when and where content changes. Three dynamic views support the publishing cycle.

Developing New Content

The web_devel view is used to design site enhancements. Developers prototype and test new content designs in this view. New development is done on a new branch, to isolate changes from the other views. This is the config spec for this view:

element * CHECKEDOUT
element * /main/devweb/LATEST
element * /main/LATEST -mkbranch devweb

When developers are satisfied with new work, they check in their changes to the devweb branch. If a file does not meet the publication submission standards (see Testing Source Files Before Checkin), the checkin fails, and the developer must fix the problems and attempt the checkin again.

Merging and Testing Approved Changes

Development team leaders use the web_merge view to merge changes from the devweb branch to the main branch. Before checking in the merged changes, the team leaders test them. This is the config spec for the web_merge view:

element * CHECKEDOUT
element * /main/LATEST

The team leaders use this command to find changes that need to be merged:

cleartool findmerge . -all -fversion \main\devweb\LATEST -query -merge

Viewing and Testing Content

The web_public view is used for internal intranet access and provides a read-only view of the latest version of the content. The config spec for this view contains one rule:

element * /main/LATEST -nocheckout

New baselines for the Web site are tested extensively in this view. Thus, problems are identified and fixed before updated files are transferred to the external staging area.

Accessing Content from a Web Browser

To access files from a Web browser, the Web team uses different server port numbers to load each dynamic view through different URLs. For example, after the server process is started at ports 80, 5990, and 6990, each view is accessible through these URLs:

For information on configuring multiple dynamic views on an Apache or Netscape Web servers, refer to Configuring the Web Server.

Implementing Policies

The following sections describe how the Web team uses ClearCase to enforce policies.

Testing Source Files Before Checkin

When a developer tries to check in a file on the devweb branch, a trigger fires and runs a script that performs the following tasks:

• It writes an entry to a report log to track the state of checkins and checkouts at the Massachusetts site. The Massachusetts Web administrator uses the report log to audit all development work.

• It runs a link-check script to check any hypertext or image references in the file. Relative paths are used in URL addresses so that all hyperlinks work regardless of which view is being accessed.

• It checks for ALT tags for all images and consistent page background colors.

• It checks for stylistic consistency, including font face and font size.

If the script finds any problems, the checkin fails and the developer receives an e-mail message that lists the problems. If the script does not find any problems, the checkin succeeds.

Restricting the Users Who Can Approve Changes

Only the team leaders are allowed to check in changes on the main branch. To enforce this policy, the main branch type is locked for all users except the team leaders. For example:

cleartool lock -nusers emma,greg,maia brtype:main@\web

This lock prevents all users except emma, greg, and maia from checking out versions from the main branch of any element in the VOB.

Labeling Approved Sources

The team uses date-based labels to indicate which files have been published on the external Web site. The publishing team applies the label before copying the latest files on the main branch to the Web server.

cleartool mklbtype -c "June 1, 2000 update" WEB_UPDATE_2000_06_01@\web

cleartool mklabel -recurse -c "June 1, 2000 update" WEB_UPDATE_2000_06_01 \web

Synchronizing the Massachusetts and California VOB Replicas

The team uses the MultiSite synchronization scripts to synchronize the replicas:

1. In Massachusetts, the sync_export_list script runs every night to send changes to the California replica. The team uses the ClearCase scheduler run the script nightly.

2. When a synchronization update packet is received at the California replica, the sync_receive receipt handler runs to import the packet. The sync_receive script is listed as the receipt handler in the shipping.conf file on UNIX or MultiSite Control Panel on Windows.

For more information about synchronization, see the Administrator's Guide for Rational ClearCase MultiSite.

Copying Files to the Web Server

Because the Web server is outside the firewall, the publishing team uses custom scripts to copy files from the VOB replica to the Web server. The script uses a view that selects the latest versions on the main branch.

Rolling Back to Previously Published Versions

If any problems occur with published material, the publishing team can use a ClearCase view to select a previous baseline and copy those files to the Web server. For example, the team uses a view with the following config spec to roll back to the files published on May 15, 2000:

element * WEB_UPDATE_2000_05_15