|Last updated||2002-07-08 13:53:30 EDT|
|Doc Title||DLPS's DLXS Development Environment|
|Author 1||Farber, Phillip|
|Author 2||Pagliere, Alan|
|CVS Revision||$Revision: 1.8 $|
This document describes various aspects of the development environment used at DLPS. There may be, for example some reasonable assumptions about the specific DLPS development environment in parts of our middleware (consulting certain environment variables, etc.). However, the DLXS system does not absolutely rely on most of these in order to work, i.e. in a more "plain vanilla" environment that might be set up by a DLXS site. Nontheless, there are valuable mechanisms to support development built into DLXS you may wish to take advantage of.
We use CVS to handle source control, merging of multiple developers' code, tagging specific configurations of many files, releasing particular tagged versions of files, etc. The CVS source repository stands between each developer's work space and what we call the release directory structure. Each developer's work space is volatile and is expected to change frequently.
Completed work is committed to the CVS repository from the developer's workspace by issuing the cvs commit command. The release directory structure is updated via the cvs update command which pulls the committed source out of the CVS repository and into the release directory structure.
The release directory structure is semi-stable and does not change as frequently. We never modify files in the release directory structure directly. We always change files in the work directory, commit to CVS, and update into the release directory structure.
The release directory structure is an integration test area used to determine if changes from multiple developers work together. Finally we copy the release directory structure to one of our production machines after it has been tested. The production directory structure is the most stable environment.
In the absence of CVS you will need to copy files from your work directories to the release directories manually or with the aid of scripts. Of course, without CVS or a similar source control system, you will not have file versions, merging, etc.
At DLPS, we have separate work directories that mirror most of the release/production directory structure. This allows us to have multiple developers working on code, making changes to collection databases, etc. at the same time.
We use a development model designed to support a workspace (directory structure and environment) for each developer separate from the release directory structure. As of Release #9, this structure will supercede the work directory model that used the special URL syntax in previous DLXS releases. In the virtual-host-based model, a virtual host is configured on the web server for each developer.
Here is an example Apache virtual host configuration supporting a workspace for smith:
<VirtualHost 123.456.789.123:80> ServerName smith.dev.umdl.umich.edu ServerAlias smith smith.dev smith.dev.umdl DocumentRoot /l1/dev/smith/web ScriptAlias /cgi/ /l1/dev/smith/cgi/ SetEnv DLXSROOT /l1/dev/smith SetEnv DLXSDATAROOT /l1 SetEnv DLPS_DEV smith SetEnv REMOTE_USER smith </VirtualHost>
Note that the DocumentRoot and ScriptAlias point to /l1/dev/smith under which is smith's set of development directories, in particular cgi and web.
Each developer has a domain, e.g., smith.dev.umdl.umich.edu. Each virtual host sets a unique DLXSROOT environment variable value that points to a complete DLXS directory structure. For example, smith has a DLXSROOT value of /l1/dev/smith. Into this directory we check out the CVS repository. This gives each developer a mirror of the entire CVS development directory structure.
To run smith's development copy of the middleware the basic URL (e.g. TextClass) would be: http://smith.dev.umdl.umich.edu/cgi/t/text/text-idx
DLPS_DEV is the environment variable that signals to the middleware that it is running in development mode. The virtual host should set DLPS_DEV to the user ID that identifies smith to the system, e.g smith. At DLPS we use the developer's uniqname. If you maintain a "release" directory tree (separate from each developers' directory tree) where code from multiple developers is brought together for integration set DLPS_DEV to "1" for the virtual host that runs middleware from this area.
When running in development mode (the DLPS_DEV environment variable is set) the middleware supports a number of mechanisms to assist debugging and general development:
This mechanism is a part of a facility in collmgr which gives each developer a set of collection database rows. This allows each developer to experiment with database changes without affecting the rows in use by the released middleware. Additional information on this mechanism is available in the collmgr documentation.
The DLXSDATAROOT environment variable allows the data to be under a different directory root than the middleware programs. We created DLXSDATAROOT because data and indexes are too large to duplicate for each developer and are not generally CVS source controlled. Each virtual host sets this variable to point to the root of the release directory structure (outside of the developer's workspace) that contains the obj and idx directories where data and indexes reside. DLXSDATAROOT is optional. If it is set, the middleware favors it over DLXSROOT when accessing data and indexes. If it is not set, the middleware will use DLXSROOT to locate the data. In that event, you would need a copy of the data directories and their content in your development space.
The REMOTE_USER environment variable is set for convenience to mimic the action of the authorization system which is absent on the development machines. The middleware determines whether the user is logged in by testing REMOTE_USER for a value.