# SEE 16.11.2022 Notes - Release Management

## Overview / Current context

We have a semi-automated BTD (build-test-deploy) process. At this stage, the release validation is largely done manually, release notes as well, and deploying an item to production is a multi-step manual process that requires tribal knowledge.

## Goals
- [ ] Release Cycle and Lead time reduced

## Current state

- [ ] Data migration is hard to validate. Migrations run in parallel when multiple instances of the server are used which breaks them frequently.
- [ ] BACKUPS ARE HARD TO RESTORE. Require tribal knowledge. Canvas templates are huge and break the restore. Lead time of data restore is very high.
- [ ] Release notes written manually
- [ ] Release validation done largely by QA(Evgeni) and not distributed among the team
- [ ] Builds in acceptance, demo, production don't validate deployments in multiple namespaces leading to false negative failed builds
- [ ] Version management is done manually
- [ ] Repetetive work done manually
- [ ] No release checklist
- [ ] Authorization reset is done manually with personal accounts
- [ ] Release scope + timeline is almost always unclear. Release planning should be improved. Regular release cadance?
- [ ] Translations are also done manually now
- [ ] We have QA column with many items in progress just before the release
- [ ] Frequently disruptive changes before a release
- [ ] Always rushing the release
- [ ] Release notes on infra-ops done manually
- [ ] Access control & approvals of the release process coupled with the infrastructure definitions
- [ ] Release process is not documented
- [ ] Github actions are outdated
- [ ] Pull Requests not always manually validated by the reviewer
- [ ] NPM packages pushed to npmjs manually

## Desired state

- [ ] Release checklist available and verified with each release
- [ ] Release flow documented with diagrams
- [ ] Access control & approvals of the release process de-coupled from the infrastructure definitions
- [ ] Migrations run BEFORE the server. If the migration fails backup needs to be restored automatically. If the backup fails a list of users receive a notification.
- [ ] Data backups restored in ~5 minutes with no tribal knowledge involved (just run a single sql command)
- [ ] Release notes built up from commits (e.g. the way Ory does that)
- [ ] Client regression suit with smoke tests (sanity checks)
- [ ] Semantic versioning with tooling
- [ ] Optionally AHT
- [ ] PRs always functionally validated by the reviewer (at least the straight case)
- [ ] Authorization reset done with service account as part of the deployment. Feedback provided if it fails.
- [ ] No false negatives regarding the deployment state.
- [ ] Release planning improved - scope, timeline of all releases in a sprint agreed up front (at the beginning of the sprint)
- [ ] NPM packages pushed to npmjs with github action

## Actions
- [ ] @Valentin - Evaluate Github Enterprise
- [ ] @Valentin @Evgeni - create release checklist
- [ ] @Valentin - create diagrams + documentation about the release process
- [ ] @Valentin @4wrEm8T9TJWmfygK5dQIvA data migrations automated (sidecar) + validated before the server starts
- [ ] @4wrEm8T9TJWmfygK5dQIvA - Release planning
- [ ] @4wrEm8T9TJWmfygK5dQIvA - Translation process integrated in the release

###### tags: `SEE`, `Release Management`, `DevOps`