Releasing a new version of Quattor

Introduction

As discussed in the 15th Quattor workshop, I detail here the tools and means for a Quattor release. This document should be kept up to date as the release procedure gets more automated.

For the client code (configuration modules, core libraries...), we do one release each 4-6 weeks. The "certification" process is manual, here is how it goes:

Release branch

When the time comes, the release manager (RM) creates a new branch in the main GitHub repository, on each repository that will be released. He ensures that the builds in the ​Jenkins repository pass. If they don't, he iterates with the authors or reverts the commits that break the tests.

Testing the release

When all tests seem to pass, the RM creates all the packages and uploads them to some Yum repository. He will then update all templates in a sandbox, and deploy the site.

NOTE: We don't have the manpower to produce test profiles for each component. Only the most important ones are being stressed ATM.

NOTE: We'd appreciate a number of virtual machines (or a test site in the cloud) to make even more thorough tests.

Declaring victory

When all the installations and component executions succeed, the RM executes the following command line on all the repositories:

$ mvn -q -DautoVersionSubmodules=true -Dgpg.useagent=true -Darguments=-Dgpg.useagent=true -B -DreleaseVersion=$VERSION clean release:prepare release:perform

Uploading to the Git repositories

The ​release repository contains a POM file with all the artifacts that should be uploaded to the Yum repositories, with their releases. Just adjust it.

Tools

The releasing.org file is an useful checklist to keep track of which modules we have already validated.

TODO

We need to push the templates to the QWG repositories during the release. Put the script in the release repository.