Shipping weekly without breaking things: release discipline for a small team

We release often because that is how we learn what the next release should be. Releasing often is also how you ship a bug to everyone at once. These are the habits that keep the second thing from happening.

Small releases fail small

A release with one meaningful change is easy to understand, easy to test and easy to reverse. A release with fifteen is none of those. If a change is big, it ships in pieces behind a flag, and the release that turns it on is a release with one change.

Phased release, every time

The App Store can roll an update out gradually over a week. We use it for every release, without exception. If crash rates move or reviews turn, the rollout pauses and most users never see the problem. It costs nothing and it has saved us more than once.

Feature flags

New features ship off, behind a flag, and are turned on remotely for a small share of users first. The release and the launch are separate events. If a feature misbehaves, it is switched off in minutes without a new build and without App Review.

The checklist before submit

• Fresh install on a real device, the oldest one we support.
• The full first session, including purchase and restore, with a real sandbox account.
• The night-time flow with the screen locked and the timer running.
• The till flow, scanned by a real camera.
• Release notes that say what changed, in plain words.

Nothing ships on a Friday

A release that goes wrong on a Friday evening is a weekend of a bad experience for users and a worse one for the person who owns the app. Releases go out early in the week, when there is time to watch them.

Watching after

For the first day of a rollout the owner watches crashes, reviews and the support inbox. Most problems show up in hours. A release is not done when it is approved; it is done when a few days of real users have said nothing.