From b0515730e334a2d21e31168e0860fb3feb48f531 Mon Sep 17 00:00:00 2001 From: Brian Thorne Date: Fri, 18 Oct 2019 17:19:01 +1100 Subject: [PATCH] Add developer documentation on the release process. (#455) * Add developer documentation on the release process. --- docs/development.rst | 4 ++++ docs/releasing.rst | 30 ++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 docs/releasing.rst diff --git a/docs/development.rst b/docs/development.rst index 27ba91a1..2c260df1 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -6,6 +6,8 @@ Development changelog future + releasing + Implementation Details ---------------------- @@ -113,3 +115,5 @@ to which the results are written (as ``results.xml``). During the testing the py and then the Job's pod terminates. We create a temporary pod which mounts the same results volume and then we copy across the produced artifact for rendering in Jenkins. This dance is only necessary to retrieve files from the cluster to our Jenkins instance, it would be straightforward if we only wanted the stdout from each pod/job. + + diff --git a/docs/releasing.rst b/docs/releasing.rst new file mode 100644 index 00000000..bb5d8b7a --- /dev/null +++ b/docs/releasing.rst @@ -0,0 +1,30 @@ + +Releasing +========= + +Releasing a version of the Anonlink Entity Service +-------------------------------------------------- + +We follow gitflow. Each release has a GitHub milestone associated with it which groups all the features and +bug fixes together. + +Multiple docker images are contained within this repository (e.g., ``backend``, ``frontend``, ``benchmark``) which +are independently versioned. In general a release involves a new version of both the ``backend`` and the ``frontend``. +This is because the documentation is baked into the frontend so user visible changes to the backend require a new +frontend. + +- Choose a new version using semantic versioning. +- Create a branch off the latest ``develop`` called ``release-x.y.z``. +- Update the versions in the code base (e.g., ``backend/entityservice/VERSION``) of any components that have been + changed. As above note if the backend version has changed you must release a new frontend too. +- Update the changelog to include user friendly information on all features, taking special care + to mention any breaking changes. +- Open a PR to merge these changes into ``develop``, and get a code review. Make any requested changes, and merge the + changes into ``develop`` (don't close the branch). +- Open a PR to merge the release branch into ``master``, only proceed if the CI tests all pass. Merge, rather than + squashing the commits. +- Create a git tag of the form ``vX.Y.Z[-aN|-bN]`` (e.g. using GitHub's releases ui). +- Tag and push release versions of docker images from this tag and the tag `latest` (manually for now but ideally using CI). +- Commit to develop (via a PR) creating a new ``"Next Version`` section in the changelog. +- Proudly announce the new release on the anonlink google group https://groups.google.com/forum/#!forum/anonlink +