DLPS DLXS Development Environment Scenarios

Here are various scenarios to illustrate how we use CVS, multiple rows in the dlxs database, multiple servers (development, production and data prep machines), and rdist to manage all aspects of code development, deployment and release. Follow along with this diagram in a separate window.

As you read through the scenarios, keep in mind the following about the development environment at DLPS:

Scenarios:

 

Scenario 1: one developer changing code, testing, and committing changes

Developer pagliere works on a file in his own sandbox or "dev space", /l1/dev/pagliere/cgi/t/text/TextClass.pm. Since his virtual host http://pagliere.dev.umdl.umich.edu/ sets his $DLXSROOT to /l1/dev/pagliere, all his middleware uses modules such as /l1/dev/pagliere/cgi/t/text/TextClass.pm and /l1/dev/pagliere/lib/DlpsUtils.pm, etc. He tests his code. He decides it is self-consisitent and working. He runs cvs commit or the DLPS script commitme pagliere text or uses his xemacs cvs-mode to commit his changes to the repository.

The next time other developers cvs update their own dev spaces (see Scenario 2), they will have pagliere's code merged into theirs.

Scenario 2: updating a developer's code with the latest changes

Developer pfarber runs cvs update or the DLPS script updateme pfarber all or uses xemacs in cvs-mode to cvs update code in his own dev space. All changes that were committed to the repository are merged into pfarber's code.

Scenario 3: data update, testing of new data and move to production

Developer sooty receives new data for a collection. She deposits it in the /l1/prep/c/coll on the data prep machine. She adjusts all her prep scripts, runs them, and creates new data files in /l1/obj/c/coll and corresponding indexes in /l1/idx/c/coll. She opens collmgr, and changes her own row in the dlxs database so that the host field points to the development machine. When she runs her code, through the browser or the debugger, all requests for data via XPat will go to the development machine and its new data.

When she is satisfied that the new data is working correctly, she rdists the /l1/obj/c/coll and /l1/idx/c/coll directories over to the production machine (and, if necessary, to the development machine). She changes the value of the host field back to the production machine, if she desires.

Scenario 4: updating the "release" directory to test multiple developers' changes

Several developers have been working on different parts of the code, merging (via cvs update and cvs commit) their code with the repository's latest/ever-changing code. One developer runs a DLPS script called updaterelease. which cvs updates the so-called release directories, /l1/cgi/ and /l1/lib/ and /l1/web and /l1/lib, etc. General testing is done by everyone in the release area.

Scenario 5: moving latest code to production

After the release area's code is tested and felt to be working properly, a build production package script is run which gathers up the latest versions of all the (/l1/cgi/ and /l1/lib/ and /l1/web and /l1/lib, etc.) and rdists it all to the production machine.

Scenario 6: tagging and releasing a DLXS Release

After code has been running for a certain length of time in production and it is decided to release to the DLXS community an official DLXS Middleware Release, a build release package script is run which gathers up the latest versions of all the (/l1/cgi/ and /l1/lib/ and /l1/web and /l1/lib, etc.), cvs tags it all and places it in a particular directory on the development machine so that it can all be burned to CD.

Back to top