Software Configuration Management

See also: Software/ConfigManagement/SubversionBranchMngmt

In order to manage the integration and deployment of incremental developments to the CEDA NDG components, the following process is proposed for use within the CEDA development team.

  • Do some development (including unit test(s))
  • Test component on developer's own sandbox
  • Test against other dependencies on developer's own test deployment environment
  • Tag as ready (in SVN) for testing in integration environment (currently neptune, aka ndg3beta)
  • Coordinate with group to create a "known working combination" of components
    • (this step should relatively infrequent because of test deploying in developer's own environment)
    • To be put in labelled subfolder in
      • Actual components (eggs, jars) go in top level of dist. Combination created by making symlinks to components.
      • ...or list in zc.buildout config file, & point to this config file from above subfolder
    • All components in combination list must be versioned
    • To include description of neptune environment setup (eggs, jdk, all relevant environment components incl linux distro) as readme file.
    • To include all config files where possible
  • To include communication (ndg-technical) notifying scheduled date/time for change over to new release
  • Deploy release
  • (Roll back to previous release, preserved in dist, if unsuccessful)


  • All source code is already managed with SVN.
  • Need defined milestones representing significant releases on neptune
  • Neptune will be public-facing
    • Sensitive data (e.g. Dom's test datasets) may mean IP-restricting some deployed services (e.g. WCS) until the security stack has matured enough to be fully plugged in.