Initial framework for SD-Core Docs
Change-Id: I441247158203b718d9ed5e53c1aefc812139fd6e
diff --git a/release/process.rst b/release/process.rst
new file mode 100644
index 0000000..4fce892
--- /dev/null
+++ b/release/process.rst
@@ -0,0 +1,118 @@
+Release Process
+===============
+
+Prerequisites
+-------------
+
+SD-Core makes the following assumptions about the components are included in a
+release:
+
+Git tags
+""""""""
+
+Code receives Git tags as a part of the CI process
+
+* Tag content comes from a **VERSION** file within the repo, and tags are
+ created only the version is a SemVer released version (example: ``1.2.3``, no
+ ``-dev`` or ``-rc`` extensions)
+
+* Tagging is *only done by the CI system* (Jenkins), which pushes tags to git
+ repos after a submit/merge of code which changes the **VERSION** file.
+
+* CI system enforces tag uniqueness - no two commits have the same released
+ version tags.
+
+ * You can't re-release or "fix" a version that has problem - make a new
+ version with fixes in it.
+
+Docker container images
+"""""""""""""""""""""""
+
+All docker images are tagged based on their git tags.
+
+* For released versions, the CI system should prevent a Dockerfile from
+ referencing a parent containers that are a moving target, such as ``latest``
+ or ``master``.
+
+ * This allows a container to be rebuilt given an arbitrary git commit with
+ fair confidence that it will result in the same code in the container.
+
+* Official images are only pushed to registries by the CI system
+
+ * Increases repeatability of the process, and prevents human accidents.
+
+Helm charts
+"""""""""""
+
+* Each chart may only contain references to released, SemVer tagged container images
+
+ * Chart CI process must check that a chart version is unique - a chart can't
+ be created with the same version twice. This should be done against the
+ chart repo.
+
+Release Steps
+-------------
+
+All Helm charts are checked that the containers they use have a SemVer version
+tag
+
+A branch is created on the Helm charts repo, with the abbreviated name of the
+release - for example **sdcore-1.0**.
+
+To allow for future patches to go into the repo in a way that does not conflict
+with the version branch, each component repo's **VERSION** file should have it's
+minor version increased. (ex: 1.2.n to 1.3.0-dev, so future 1.3.n+1 component
+release can easily be created).
+
+The same should be done on Helm charts in the chart repos post release, but the
+versions there shouldn't include a ``-dev`` suffix because chart publishing
+requires that every new chart version be unique and unsuffixed SemVer is a
+more consistent release numbering pattern.
+
+Finally, the ``sdcore-helm-charts`` repo overall **VERSION** should also be incremented
+to the next minor version (1.6.0-dev) on the **master** branch, so all 1.0.x
+releases of the overall charts repo will happen on the **sdcore-1.0** branch.
+
+Creating releases on the 1.0.x branch
+"""""""""""""""""""""""""""""""""""""
+
+If a fix is needed only to the helm charts:
+
+1. Make the fix on the master branch of sdcore-helm-charts (assuming that it is
+ required in both places).
+
+2. After the master tests pass, manually cherry-pick the fix to the **sdcore-1.0**
+ branch (the Chart version would be different, requiring the manual step).
+
+3. Cherry-picked patchsets on that branch will be checked by the **sdcore-1.0**
+ branch of tests.
+
+4. When it passes, submitting the change will make a new 1.0.x release
+
+5. Update the documentation to reflect the chart changes, a description of the
+ changes m, and increment the tag on the docs from 1.0.n to 1.0.n+1, to
+ reflect the patch change.
+
+6. If all the charts are updated and working correctly, create a new charts
+ point release by increasing the 1.0.n **VERSION** file in the
+ sdcore-helm-charts repo. This should be the same as the version in the
+ documentation. Immediately make another patch that returns the
+ ``sdcore-helm-charts`` **VERSION** to 1.0.n+1-dev, so that development
+ patches can continue on that branch.
+
+If a fix is needed to the components/containers that are included by the helm charts:
+
+1. Develop a fix to the issue on the master branch, get it approved after
+ passing master tests.
+
+2. If it doesn't exist, create an **sdcore-1.0** branch on the component repo,
+ starting at the commit where the **VERSION** of the component used in 1.0 was
+ created - this is known as "lazy branching".
+
+
+3. Manually cherry-pick to the **sdcore-1.0** branch of the component, incrementing
+ the patch version, and test with the **sdcore-1.0** version of
+ sdcore-system-tests and helm charts.
+
+4. Update helm charts and go through the helm chart update process above
+