Changes between Initial Version and Version 1 of Obsolete/Development/ReleaseProcess

Timestamp:

Mar 7, 2013, 6:08:10 PM (13 years ago)

Author:

munoz

Comment:

--

Obsolete/Development/ReleaseProcess

@@ +1 @@
+= Releasing a new version of Quattor =
+
+[[TOC]]
+
+== 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 [https://jenkins1.ugent.be/view/Quattor 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:
+
+{{{
+#!sh
+$ mvn -DautoVersionSubmodules=true -B -DreleaseVersion=$VERSION release:prepare
+$ mvn -DautoVersionSubmodules=true -B release:perform
+}}}
+
+== Uploading to the Git repositories ==
+
+The [https://github.com/quattor/release.git 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.