commit 9f6e898cc2bced446b3e65cdab4387b3437f0702
parent b9dc01946bdfceb9c67aa29b87e1b4046165b712
Author: Florian Dold <florian@dold.me>
Date: Wed, 8 Jul 2026 19:58:01 +0200
first draft of prod release process
Diffstat:
1 file changed, 115 insertions(+), 0 deletions(-)
diff --git a/developer/prod-release-process.rst b/developer/prod-release-process.rst
@@ -0,0 +1,115 @@
+Production Release Process
+==========================
+
+This document describes the process that our team follows for releasing into
+production. The goal is have better visibility into the release process,
+allowing us to improve the checks done before a release.
+
+Scope
+-----
+
+The process described here applies to:
+
+* Upgrades of production environments (merchant, exchange, ...)
+* Publishing of production-track apps (wallets, merchant PoS, ...)
+
+It does currently *not* apply to:
+
+* Upgrading internal or staging environments
+* Publishing tesing-track apps
+* Publishing/promoting Debian packages *even* on a release track
+
+Process
+-------
+
+The process is done by the release manager.
+
+1. Release manager or another team member creates Mantis issue for the release.
+ The issue title should be of the form ``deploy/release $component ($version)
+ on $environment``. The version can contain a placeholder (``v1.6.x`` or
+ ``next``) if the final minor or patch version is now known yet.
+ Creating this issue should be done as soon as the need for a release in the current
+ milestone becomes apparent.
+
+ If there is a target date for the release, it should be specified in square
+ brackets after the title (``[2026-01-01]``).
+
+2. If any issues need to be resolved for the release, they should be marked as
+ related bugs to the deployment bug.
+
+3. Once the release is ready (based on related bugs, testing and the target
+ date), the release manager fills out the sign-off template and posts it as a
+ Mantis comment.
+
+ The tests done for the deployment should be based on the pre-deployment
+ sign-off of earlier deployments and/or component-specific checklists.
+
+4. For the deployment of highly critical components, a second sign-off may be
+ necessary.
+
+5. The release manager (possibly in collaboration with other team members)
+ executes the steps required for the deployment.
+
+6. The release manager posts the post-deployment report.
+
+7. Once all issues in the post-deployment report have been addressed *and* the
+ deployment is live (i.e. apps were approved in the store), the deployment
+ bug is marked as resolved.
+
+
+Pre-Deployment Sign-off template
+--------------------------------
+
+.. code:: markdown
+
+ # Pre-deployment Sign-off
+
+ Scope:
+ - (list apps or environments affected)
+
+ Relevant hosts:
+ - (if applicable, list affected hosts)
+
+ Relevant tags:
+ - (list git tags that uniquely identify what will be deployed)
+
+ Known critical bugs:
+ - (list known critical bugs)
+
+ Tests:
+ - (list tests that were done, both manual and test suites)
+
+ Special considerations:
+ - (list anything that is out of the ordinary, such as breaking changes,
+ hotfix, ...)
+
+ Other accepted risks:
+ - (list accepted risks such as specific untested features, known instabilities, ...)
+
+ Sign-off:
+ - $NAME, $DATE
+
+Post-deployment report template
+-------------------------------
+
+.. code:: markdown
+
+ # Post-deployment report
+
+ Timeline:
+ - (include relevant timeline items, such as submitted/accepted for apps)
+
+ Post-deployment checks:
+ - (list what you've done to test that the deployment succeeded)
+
+ Issues addressed:
+ - (if applicable, list anything that was out of the ordinary before or after the deployment and had to be addressed)
+
+ Other issues:
+ - (list any other relevant issues that you noticed during/after the deployment)
+
+
+Examples
+--------
+
+* https://bugs.gnunet.org/view.php?id=11558 (with older version of the template)
