Add developer documentation on the release process. (#455)

* Add developer documentation on the release process.

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.
+
+

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
+