Checkliste für den Start von Apps #

Diese Checkliste richtet sich an das App-Team und an die Personen, die die Exponential-Installation betreiben, in der Woche, bevor die App gegen die Produktion live geht. Jeder Punkt verweist auf die Seite, die ihn erklärt.

Inhalt #

1. Die Installation
2. Konten und Zugangsdaten
3. Inhalte
4. Leistung
5. Fehler und Überwachung
6. Nach dem Start

Die Installation #

• To do: Die Prüfanfragen antworten auf der Produktionsadresse wie erwartet (Erst prüfen, dann bauen).
• To do: ezprestapi 1.2.6 oder neuer ist aktiv und ezprestapiprovider ist entfernt (API-Versionen v1 und v2).
• To do: expservices ist aktiv, wenn die App Remote-Dienste nutzt, und seine Token-Tabelle existiert.
• To do: Die Basis-URL der App ist Konfiguration und zeigt im Release-Build auf die Produktion.

Konten und Zugangsdaten #

• To do: Der Integrationsbenutzer und seine Rolle existieren in der Produktion, nicht nur im Staging.
• To do: Der OAuth-Client ist in der Produktion mit der exakten Weiterleitungsadresse der Produktion registriert.
• To do: Produktionsschlüssel und -Secrets liegen im Geheimnisspeicher des Backends, und die Testschlüssel sind widerrufen.
• To do: Die Sicherheitscheckliste ist abgearbeitet.

Inhalte #

• To do: Die Einstiegsordner existieren in der Produktion mit den Remote-IDs, mit denen die App konfiguriert ist (Knoten-IDs, Remote-IDs und Deep Links).
• To do: Jede Klasse, die die App zeigt, hat Elemente, und die Felder, die die App braucht, sind ausgefüllt.
• To do: Die Bildaliase, die die App verwendet, existieren in der Produktion (Bildaliase für Bildschirmgrößen).
• To do: Redakteure wissen, welche Felder die App zeigt und wie lange es dauert, bis eine Veröffentlichung dort ankommt (Entwürfe, Vorschau und Veröffentlichung).

Leistung #

• To do: Listen werden mit kleinen Limits seitenweise geladen; Detailaufrufe werden nicht pro Zeile gemacht (Antwortgruppen).
• To do: Die App speichert mit stale-while-revalidate zwischen (Caching in der App).
• To do: Ein Backend, das einen einzigen API-Schlüssel verwendet, bleibt unter RateLimitPerMinute.
• To do: Das Serverteam kennt den erwarteten Verkehr, und die TTL des REST-Caches ist abgestimmt (Caching auf dem Server).

Fehler und Überwachung #

• To do: Jeder Status aus Fehler und Statuscodes wird behandelt, auch 429 und Zeitüberschreitungen.
• To do: Die App meldet API-Fehler mit Route, Status und Uhrzeit an Ihr Absturz- oder Analysewerkzeug, ohne Zugangsdaten.
• To do: Jemand beobachtet in den ersten Tagen die Ablehnungen im Prüfprotokoll.
• To do: Der Support kann „die App ist ausgefallen“ von „die Website ist ausgefallen“ unterscheiden (Zuverlässigkeit des App-Backends).

Nach dem Start #

• To do: Der Upgrade-Plan des Servers enthält zuerst einen Test der App gegen die neue Version (Eine lokale Testinstallation).
• To do: Klassenänderungen, die Felder der App berühren, werden dem App-Team angekündigt.
• To do: Die Termine für den Austausch von Schlüsseln und Secrets stehen im Kalender.

Verwandte Seiten #

• Mobil-Checkliste (für Unternehmen)
• Bereit für die App-Store-Prüfung
• Bereitstellungs-Pipeline
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.