Background

• In order for the testing process to be effective and give meaningful feedback on how the same code would behave on the production machine, the test machine should reproduce as much of the environment of the production machine as possible. However, care should be taken for the tests to not destructively interfere with the production environment by, for example, changing data in the database. Replicating a subset of the data used by the production machine should presumably allow both unrestricted testing and prevent said destructive interference

• Initially, most of the steps would be done manually, or semi-manually (with simple scripts chaining simple sequential operations). It would however be desirable to eventually automate the whole process as much as possible.

• Exceptions to this release process should only occur if, by chance, critical problems slip into the production portal. Critical problems are problems that would prevent the proper functioning of the portal, and do not include aesthetic or spelling issues

• A mechanism should exist on the production portal that indicates the exact version of the code that is deployed. The suggestion is:

  /elab/name/version.jsp

  This page can be generated as part of the deployment process, and does not need to exist in the repository

The following URLs can be used to verify the versions of the deployments:

• Testing machine (now down due to a hardware problem): http://www17.i2u2.org:8080/elab/cosmic/version.jsp
• Temporary testing machine: http://www15.i2u2.org:8080/elab/cosmic/version.jsp
• Production: http://www11.i2u2.org:8080/elab/cosmic/version.jsp

Repository Commit Policy

• Commits to the stable repository should not include major functionality changes that have the potential to break things. Before committing, developers should take reasonable steps to ensure that the commits do not have undesired consequences. This may include testing of individual pages/components on a development machine, but is generally left at the discretion of the committer.

• As a general rule of thumb, it is desirable for the stable repository to always be usable for deployment on a production portal. While this is not in practice always achievable, committers to the stable repository should keep that goal in mind

• Commits can happen at any time, given that the other parts of the policy are followed

Release Steps

1. Make sure you are in the quarknet group on the *.i2u2.org cluster

2. Tag Repository:

   > cvs tag Tagname

   or

   export CVSROOT=:ext:cvs.ci.uchicago.edu:/var/cvsroot
   cvs rtag Tagname i2u2 
   

   where Tagname is an identifier of the form: RELEASE_Version_Release

   The release number is increased by one with every subsequent release

3. Deploy the tagged version on the test machine (www17.i2u2.org)

   1. Log into www17.i2u2.org
   2. > cd /home/quarkcat
   3. > ./deploy-from-cvs Tagname

      where Tagname is the exact version to be deployed or HEAD.

      The script will ask for two passwords: your CI password (for the CVS checkout) and your www17.i2u2.org login password (in order to run things as quarkcat)

4. Run integration tests on test machine deployment

   1. Log into www17.i2u2.org
   2. > cd /home/quarkcat
   3. > sudo -u quarkcat ./runtests.sh

   The results will then be available on http://www17.i2u2.org:8080/tests/results.html

5. If all tests succeed, move to the next step, else fix the problem and move back to step 1.

6. Deploy the tagged version on the production machine (www11).

   The deployment time window is Sat 0400 UTC to Sat 0700 UTC (Friday 2200 CST to Sat 0100 CST)

   1. Log into www11.i2u2.org
   2. > cd /home/quarkcat
   3. > ./deploy-from-cvs Tagname

7. Run integration tests on test machine deployment

   1. Log into www11.i2u2.org
   2. > cd /home/quarkcat
   3. > sudo -u quarkcat ./runtests.sh

   The results will then be available on http://www11.i2u2.org:8080/tests/results.html

8. If all tests succeed, the release is done. Otherwise a rollback should be done to the previous release