8.1. Distribution Release

8.1.1. Definitions

  • stable: the binary released version which always should be functional
  • rc: release candidate should be in consolidation
  • nightly: is for testing and new components

How to perform a csra distribution release: To perform a csra release you can use the release-csra-rc script descibed below but first of all follow the preparation steps.

8.1.2. Preparation

Update the distribution file and add hashes, tags or branches for non csra projects listed in the distribution file.

Follow these steps before performing the release:
  1. Clone the citk repository https://opensource.cit-ec.de/git/citk or make sure you have pulled the latest version.
  2. Make sure you have right access to to citk project and to the repositories hosted in at the csra redmine and the github csra project.
  3. Open the current rc distribution distributions/lsp-csra-$RC.distribution file and manually check that all projects referring to a stable version or hash except of the projects (bco.registry.csra-db-deployer, csra-utils, lsp-csra-docs, lsp-csra-system-startup, lsp-csra-system-config, fsmt-exp-csra-experiments). These seven projects should refer to the master or rc version and will be automatically branched during the release process.

Project versions referred by the latest-stable tag will be automatically resolve by the release script and replaced with the latest released project version if the tag or branch project versions are named by the semantic-versioning rules.

Example of 0.11 release

First of all we do a dry run, if no errors occur than removed the --dry-run argument and perform the release.

$ release-csra-rc --citk ~/workspace/csra/citk --distribution lsp-csra-0.16 --version 0.16 --dry-run

For a more detailed description see Release Script.

You can finde the Citk Version Updater here.

8.1.3. Jenkins

  • generate new stable distribution

  • deactivate jobs of new stable release (use regex job) (e.g. lsp-csra-0.xx)

  • delete old stable release jobs and view (the regex job can be used for deleting jobs too)

  • update versioning variables in global jenkins config here (increase all)
    • JENKINS_CSRA_VERSION_BS
    • JENKINS_CSRA_VERSION_RC
    • JENKINS_CSRA_VERSION_NIGHTLY

  • update sync-distribution job (add new release on top for default) in General->Choice Parameter->VARIANT:

    • add the new version, remove the old latest-stable, ensure rc is on top
  • update rc view
    • change version in regex
  • update nightly view
    • change version in regex

  • update backup job (adjust “Configuration Matrix” “Values” to the next two versions)

8.1.4. fsmt

TODO * what about fsmt tests?

8.1.5. Delete old releases

  • delete old stable release from all core machines
source source /vol/csra/releases/xenial/lsp-csra-rc/bin/source-env.sh
cssh_csra.sh
  • run rm -rf /vol/csra/releases/xenial/lsp-csra-{old stable release}

8.1.6. Move Databases

  • This is done automatically by Project SYNC csra to core machines
    • When a release version does not have the required databases, they are copied from MinorVersion-1 after the Sync

8.1.7. Which Database should be used after the release

The databases of the last nightly may require to be replaced by the last rc (if the rc was mostly used previously, the nightly databases are probably empty/old).

source /vol/csra/releases/xenial/lsp-csra-{version to delete}/bin/source-env.sh

ssh "$PC_DISPLAY_HALLWAY" "rm -rf "$datadir"faceidentification/"
ssh "$PC_MEMORY"          "rm -rf "$datadir"ltm-core/"
ssh "$PC_MONITORING"      "rm -rf "$datadir"grafana/"
ssh "$PC_MONITORING"      "rm -rf "$datadir"graphite/"

Run the corresponding sync job (see Step 5) afterwards to copy the databases from the previous version.

8.1.8. Transform nightly into rc distribution

  • Only perform this steps if the release of the last rc is done
  • merge system-startup feature-nightly branch into the master and vise versa
  • compare job versions of nightly and rc and use the latest version of each component for the new rc
  • ...

8.1.9. Create a new nightly distribution

  • after the current nightly version is transformed in to new rc, we need a new nightly distribution by just copy the rc.
  • update “name” and “variant” fields
  • ...