Launch checklist for apps #

This checklist is for the app team and the people who run the Exponential installation, in the week before the app goes live against production. Each item links to the page that explains it.

Contents #

1. The installation
2. Accounts and credentials
3. Content
4. Performance
5. Errors and monitoring
6. After launch

The installation #

• To do: The probes answer as expected on the production address (Probe before you build).
• To do: ezprestapi 1.2.6 or later is active and ezprestapiprovider is removed (API versions v1 and v2).
• To do: expservices is active if the app uses remote services, and its token table exists.
• To do: The app's base URL is configuration, and points at production in the release build.

Accounts and credentials #

• To do: The integration user and its role exist on production, not only on staging.
• To do: The OAuth client is registered on production with the exact production redirect address.
• To do: Production keys and secrets are in the back end's secret store, and the test ones are revoked.
• To do: The Security checklist is done.

Content #

• To do: The entry folders exist on production with the remote ids the app is configured with (Node ids, remote ids and deep links).
• To do: Every class the app shows has items, and the fields the app needs are filled.
• To do: The image aliases the app uses exist on production (Image aliases for screen sizes).
• To do: Editors know which fields the app shows and how long publishing takes to reach it (Drafts, preview and publishing).

Performance #

• To do: Lists are paged with small limits; detail calls are not made per row (Response groups).
• To do: The app caches with stale-while-revalidate (Caching in the app).
• To do: A back end that uses one API key stays below RateLimitPerMinute.
• To do: The server team knows the expected traffic and the REST cache TTL is agreed (Caching on the server).

Errors and monitoring #

• To do: Every status of Errors and status codes is handled, including 429 and timeouts.
• To do: The app reports API errors with route, status and time to your crash or analytics tool, without credentials.
• To do: Someone watches the audit's refusals for the first days.
• To do: Support knows how to tell "the app is down" from "the site is down" (App backend reliability).

After launch #

• To do: The server's upgrade plan includes a test of the app against the new version first (A local test installation).
• To do: Class changes that touch the app's fields are announced to the app team.
• To do: Key and secret rotation dates are in the calendar.

Related pages #

• Mobile checklist (for businesses)
• App store review readiness
• Deployment pipeline
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.