# Ship updates without surprises

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-release/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-release/index.md
- **Module:** Product quality
- **Time:** 45 minutes before release

A safe release answers three questions in advance: what will be checked before rollout, who will watch the first signals, and what condition will stop distribution.

## Outcome

A one-page release card covering affected user journeys, checks, owners, metrics, and stop conditions.

## A release is a controlled check, not just a Publish button

Even a small change can break login, analytics, or the path from a notification. Before publishing, the team agrees which journeys are affected, who watches the first hours, and which signal means continue, stop, or roll back.

## What you will need

- **Build:** The release build for iOS and Android, plus the previous version from the store to test the update path.
- **Team:** A release owner, a mobile developer or QA engineer, and a support contact for the observation window.
- **Window:** At least 60 minutes before publishing for checks and the first 2–4 hours after release for monitoring.

## Terms in plain language

- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Deep link — A link to a specific app screen:** Definition: After a tap, the user lands in the promised journey rather than on the home screen. Example: A push about a saved lesson opens that lesson directly.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

## When to use it

Before every update — especially when registration, data storage, notifications, deep links, or a key user journey change.

## What to open before the release

Collect the links in advance. When a problem hits, the team should not be hunting for the right dashboard or person in chat history.

- **Change list**
  - **Source:** Take the release tasks and translate them into user journeys: login, registration, content, a transaction, notifications, profile.
  - **If access is unavailable:** If there is no change list, ask each developer to state their change and the screen it might affect in one sentence.
- **Stability and events**
  - **Source:** Prepare dashboards for the crash-free rate, ANR, API errors, and key events of the new app version.
  - **If access is unavailable:** Without a dashboard, assign someone to check logs, test accounts, and support requests at 30, 60, and 120 minutes.
- **Reaction channel**
  - **Source:** Specify in advance the chat, the decision owner, and the way to halt the rollout or quickly ship a fix.
  - **If access is unavailable:** If a technical rollback is impossible, write down a safe plan: pause campaigns, disable the feature, or notify users.

## Prepare the release in five steps

1. **Translate tasks into user journeys.** Do not stop at a list of technical changes. Say what the user will see and which neighboring journey might break.
   - **Where to do it:** At the top of the release card, next to the version.
   - **Example:** Changed authorization → check login, session restore, the update from the old version, and the deep link for a signed-out user.
2. **Check a clean install and the update.** A fresh install and an update from an old version are different scenarios. Run both on iOS and Android with real test accounts.
   - **Where to do it:** In the test build and the store version.
   - **Example:** After updating from 4.2 the user stays signed in; history and settings are preserved.
3. **Walk through the critical actions.** Check login, the first useful action, the key transaction, a notification, and returning from the background. Record the fact, not “should work.”
   - **Where to do it:** In a checklist with the date, device, and the checker's name.
   - **Example:** Android 13: registration passed 10 out of 10 times; the completion event is visible in the report.
4. **Write down the stop conditions.** Before publishing, define the specific signal that stops the rollout. “If things look bad” does not help anyone decide.
   - **Where to do it:** In the last column of the release card.
   - **Example:** We stop if login conversion in the new version is more than 10% below normal or sessions start getting lost.
5. **Assign post-release monitoring.** Name the owner, the check intervals, and the reaction channel. Support must know what changed and what data to attach to requests.
   - **Where to do it:** In the chat and on the release card.
   - **Example:** Checks at 30, 60, and 120 minutes; owner — Maria; support attaches the app version and user ID.

## Practical examples

- **Before publishing: the update from 4.2:** QA updates the store version and checks the saved session and history. Losing the session or data is a pre-written stop condition, not something to argue about after launch.
- **After publishing: checkpoints:** The release owner watches the crash-free rate, login errors, and key-action conversion at 30, 60, and 120 minutes; support attaches the app version to every new request.

## Finished artifact: Release control card 4.3

One row per check. The owner, the observed fact, and the stop condition sit right next to it.

| Check | Owner | Expected result | Stop condition |
| --- | --- | --- | --- |
| Update from 4.2 | QA | Session and data preserved | Login or data loss |
| Clean registration | iOS/Android | Code and profile work | Success below 95% in tests |
| Key action | Product manager | Event and result visible | Conversion drop >10% |
| Deep link from push | CRM specialist | The right screen opens | The link lands on an error |
| First 2 hours | Release owner | Crash-free in the normal range | Sharp rise in crash/ANR |

The release owner makes the call. On a stop signal the team halts the rollout, records the time and version, notifies support, and chooses a rollback or an urgent fix.

## Release checklist

Do not tick items in advance. Every check needs a fact: device, time, result, or a dashboard link.

- [ ] Changes are translated into clear user journeys.
- [ ] A clean install and the update path are tested on iOS and Android.
- [ ] Critical actions, analytics events, and deep links work.
- [ ] Stop conditions and a safe reaction plan are written down for the key metrics.
- [ ] A release owner, monitoring intervals, and a support contact are assigned.

## What to watch after the release

- **Stability:** The crash-free rate, ANR, and API errors of the new version stay within the normal range.
- **Key journey:** Login, registration, and the main action perform no worse than in the previous version.
- **Live signals:** Support and reviews show no new recurring problem in the first 72 hours.

## Key rule

If the team does not know who stops the rollout and on which signal, the release is not ready to publish.

---

- [HTML version](https://playbook.affpartners.io/en/practices/quality-release/index.html)
- [All practices](https://playbook.affpartners.io/en/)