wiki:ReleaseProcess
Last modified 8 years ago Last modified on 02/10/11 10:47:43

Release Process

Version Control with Subversion

For version control the dCache code is kept in SVN (see Subversion for more information). Code needs to be checked out by developers. Before committing code to SVN the Review Process has to be successfully passed. Therefore, once a developer has done Unit Testing code needs to be submitted to the Review Board.

Review Board

Here the other developers can and should have a look at this code.

Code has to be reviewed by at least one of the other developers and can be committed to the trunk branch as soon as all the developers who reviewed it mark it to be shipped. When code is committed commit hooks automatically build dCache (respectively dcap or srm client). On error an email is sent to the developer who made the last commit. With the last successful build the yum repositories are updated and the rpms automatically installed on some machines.

If the code is intended to go into production branches the developer has to send a merge request to the Release Manager. Only the Release Manager can submit code to stable branches. A stable branch is any SVN branch from which releases are made.

Release Process for dCache

We have two kinds of releases:

  • The minor release
    This is a time based release (every three months). New features are introduced.
  • The patch (revision) release
    This release is done when bugs have been fixed.

Test

In order to test the new code the last dCache is upgraded and Hudson is used for testing. The Test Suite contains

  • G2 functional tests (lcg-tools)(srmcp, lcg-cp, gsiftp, dcap, gsidcap), availability of serviceports, spacemanager
  • S2 tests on a worker node
  • Parallel S2 tests
    The parallel S2 (basic and usecase suites) tests run on 7 clients and one server every hour for two days if it is a patch release and for 14 days if it is a minor release.

Release

When all tests have successfully passed code will be submitted to the website.

gLite Release Process

  • Put dcache and dcap into ETICSs
  • Build via ETICS
  • Lock by ETICS
  • Create yum repository by ETICS (by architecture and OS)
  • Submit patch request to Savannah
  • For each patch deploy on appropriate machines (fresh install and upgrade)
  • G1 test suite (configuration and functional)
  • DM test suite (lcg-cr, lcg-cp, ...) Info System working
  • S2 test suite

Collate yum install log and each test suites error and success logs. Report on any issues or by hand configuration needed.

  • Inform people that all tests have passed and start staged rollout.