Production Release Process

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

19.3.1. 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 testing-track apps

  • Publishing/promoting Debian packages even on a release track

19.3.2. 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. The report can continually be edited.

  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.

19.3.3. Pre-Deployment Sign-off template#

# 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)
- API Breaking changes
- Configuration changes
- Database migrations
- hotfix
- etc...

Other accepted risks:
- (list accepted risks such as specific untested features, known instabilities, ...)

Sign-off:
- $NAME, $DATE

19.3.4. Post-deployment report template#

# 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)

19.3.5. Examples#