prod-release-process.rst (3568B)
1 Production Release Process 2 ========================== 3 4 This document describes the process that our team follows for releasing into 5 production. The goal is have better visibility into the release process, 6 allowing us to improve the checks done before a release. 7 8 Scope 9 ----- 10 11 The process described here applies to: 12 13 * Upgrades of production environments (merchant, exchange, ...) 14 * Publishing of production-track apps (wallets, merchant PoS, ...) 15 16 It does currently *not* apply to: 17 18 * Upgrading internal or staging environments 19 * Publishing testing-track apps 20 * Publishing/promoting Debian packages *even* on a release track 21 22 Process 23 ------- 24 25 The process is done by the release manager. 26 27 1. Release manager or another team member creates Mantis issue for the release. 28 The issue title should be of the form ``deploy/release $component ($version) 29 on $environment``. The version can contain a placeholder (``v1.6.x`` or 30 ``next``) if the final minor or patch version is now known yet. 31 Creating this issue should be done as soon as the need for a release in the current 32 milestone becomes apparent. 33 34 If there is a target date for the release, it should be specified in square 35 brackets after the title (``[2026-01-01]``). 36 37 2. If any issues need to be resolved for the release, they should be marked as 38 related bugs to the deployment bug. 39 40 3. Once the release is ready (based on related bugs, testing and the target 41 date), the release manager fills out the sign-off template and posts it as a 42 Mantis comment. 43 44 The tests done for the deployment should be based on the pre-deployment 45 sign-off of earlier deployments and/or component-specific checklists. 46 47 4. For the deployment of highly critical components, a second sign-off may be 48 necessary. 49 50 5. The release manager (possibly in collaboration with other team members) 51 executes the steps required for the deployment. 52 53 6. The release manager posts the post-deployment report. The report can 54 continually be edited. 55 56 7. Once all issues in the post-deployment report have been addressed *and* the 57 deployment is live (i.e. apps were approved in the store), the deployment 58 bug is marked as resolved. 59 60 61 Pre-Deployment Sign-off template 62 -------------------------------- 63 64 .. code:: markdown 65 66 # Pre-deployment Sign-off 67 68 Scope: 69 - (list apps or environments affected) 70 71 Relevant hosts: 72 - (if applicable, list affected hosts) 73 74 Relevant tags: 75 - (list git tags that uniquely identify what will be deployed) 76 77 Known critical bugs: 78 - (list known critical bugs) 79 80 Tests: 81 - (list tests that were done, both manual and test suites) 82 83 Special considerations: 84 - (list anything that is out of the ordinary, such as breaking changes, 85 hotfix, ...) 86 87 Other accepted risks: 88 - (list accepted risks such as specific untested features, known instabilities, ...) 89 90 Sign-off: 91 - $NAME, $DATE 92 93 Post-deployment report template 94 ------------------------------- 95 96 .. code:: markdown 97 98 # Post-deployment report 99 100 Timeline: 101 - (include relevant timeline items, such as submitted/accepted for apps) 102 103 Post-deployment checks: 104 - (list what you've done to test that the deployment succeeded) 105 106 Issues addressed: 107 - (if applicable, list anything that was out of the ordinary before or after the deployment and had to be addressed) 108 109 Other issues: 110 - (list any other relevant issues that you noticed during/after the deployment) 111 112 113 Examples 114 -------- 115 116 * https://bugs.gnunet.org/view.php?id=11558 (with older version of the template)