Software-Agentur · Delivery
Veröffentlichung einer mobilen App in den App Stores
Bringen Sie das App-Update eines Kunden ohne Überraschungen in letzter Minute durch die Store-Prüfung. Der Kunde liefert Store-Angaben und Kontozugänge über einen öffentlichen Link, und nichts wird eingereicht, bevor der Engineering Lead den Build und der Kunde die Release Notes freigegeben hat.
- Dauer: 1 bis 2 Wochen
- Wie oft: Für jedes App-Store-Release
- Schritte: 10 Schritte
- KI-Agenten: 1 KI-Agent
- Freigaben: 1 Freigabe
Kostenloser Plan, keine Kreditkarte nötig.
Was sich mit dieser Vorlage ändert
Ohne Vorlage
Die App liegt im Entwicklerkonto der Agentur, und ein späterer Umzug ist mühsam.
Screenshots, Datenschutzangaben und Texte kommen am Tag vor der Einreichung.
Eine Ablehnung fällt erst auf, wenn der Kunde fragt, warum das Update nicht live ist.
Release Notes schreibt in Eile, wer gerade den Build einreicht.
Mit der Vorlage
Ab dem ersten Release werden die eigenen Konten des Kunden genutzt, mit eingeladenem Team.
Der Kunde teilt Store-Angaben und Datenschutzantworten gleich zu Beginn über einen Link.
Eine Ablehnung blockiert die Ausführung mit Grund, bis der korrigierte Build neu eingereicht ist.
Ein KI-Agent entwirft sie, der Engineering Lead korrigiert sie und der Kunde gibt sie frei.
Die Vorlage, Schritt für Schritt
Jeder Schritt zeigt, wer ihn erledigt: jemand aus Ihrem Team, ein KI-Agent oder der Kunde über einen öffentlichen Link. Eine Freigabe hält alle folgenden Schritte gesperrt, bis sie erteilt ist.
- Erledigt von Ihrem Team
- Erledigt von einem KI-Agenten
- Erledigt vom Kunden, über einen öffentlichen Link
Beginnt, wenn
Eine Version der mobilen App eines Kunden ist bereit für das Release. Der Projektmanager startet eine Ausführung mit App-Name, Version und geplantem Release-Datum.
- 1
Release planen und Link teilen
Tag 1Projektmanager · Team
Vereinbaren Sie, was in die Version kommt, tragen Sie die Release-Daten ein und senden Sie dem Kunden den öffentlichen Link mit dem, was die Stores von ihm brauchen.
Checkliste
- Inhalt des Releases vereinbart
- Öffentlichen Link an den Kunden gesendet
Auszufüllende Felder
- App-Name (Pflichtfeld)
- Version (Pflichtfeld)
- Geplantes Release-Datum (Pflichtfeld)
- 2
Kunde liefert Store-Angaben und Kontozugänge
Tag 1 bis 3Product Owner beim Kunden · Öffentlicher Link
Über den öffentlichen Link bestätigt der Kunde, dass die App unter seinen eigenen Entwicklerkonten veröffentlicht wird, lädt das Team dort ein und teilt, was die Store-Einträge brauchen.
Checkliste
- Team ins Apple-Entwicklerkonto eingeladen
- Team in die Google Play Console eingeladen
- Fragen zu Datenschutz und Datensicherheit beantwortet
Auszufüllende Felder
- Hervorzuhebende Features (Pflichtfeld)
- Link zur Datenschutzerklärung (Pflichtfeld)
- Support-E-Mail (Pflichtfeld)
- Link zu neuen Screenshots
- 3
Release-Kandidaten bauen
Tag 2 bis 5App-Entwickler · Team
Bauen Sie den signierten Release-Kandidaten mit den richtigen Versions- und Build-Nummern und verteilen Sie ihn auf die Testgeräte.
Checkliste
- Versions- und Build-Nummer gesetzt
- Mit den Zertifikaten des Kunden signiert
- Auf die Testgeräte verteilt
Auszufüllende Felder
- Build-Nummer (Pflichtfeld)
- Link zum Test-Build (Pflichtfeld)
- 4
Auf echten Geräten testen
Im öffentlichen Link ausgeblendetTag 4 bis 7QA Engineer · Team
Testen Sie den Release-Kandidaten auf den unterstützten Geräten und Betriebssystemversionen, einschließlich des Updates von der aktuell veröffentlichten Version.
Checkliste
- Auf dem ältesten unterstützten Betriebssystem getestet
- Update von der Live-Version getestet
- Store-Richtlinien geprüft
- Kein Absturz beim Start
Auszufüllende Felder
- Link zum Testbericht (Pflichtfeld)
- Bekannte Probleme
- 5
Release Notes für die Stores entwerfen
Tag 7Store-Notes-Autor · KI-Agent
Der Store-Notes-Autor entwirft die Release Notes für beide Stores aus den Features, die der Kunde hervorheben will, und den bekannten Problemen, innerhalb der Längengrenzen aus seinen Anweisungen.
Auszufüllende Felder
- Entwurf der Release Notes (Pflichtfeld)
Geprüft von: Der Engineering Lead korrigiert die Notes und gibt den Build in Schritt 6 frei.
- 6
Build für die Einreichung freigeben
Tag 8Engineering Lead · Team
Lesen Sie Testbericht und bekannte Probleme, korrigieren Sie die Release Notes, geben Sie den Build frei und mailen Sie die endgültigen Release Notes an den Kunden.
Checkliste
- Testbericht gelesen
- Release Notes korrigiert
- Build-Nummer passt zum getesteten Build
Freigabe: Die Freigabe durch den Kunden und die Einreichung bei den Stores bleiben gesperrt, bis der Engineering Lead den Build freigibt.
- 7
Kunde gibt Release Notes und Termin frei
Tag 8 bis 9Product Owner beim Kunden · Öffentlicher Link
Der Kunde liest die Release Notes, die der Engineering Lead gemailt hat, und hält über den öffentlichen Link seine Entscheidung und den Tag fest, an dem die Version live gehen darf.
Auszufüllende Felder
- Entscheidung (Pflichtfeld)
- Live am (Pflichtfeld)
- Änderungen am Text
- 8
Zur Store-Prüfung einreichen
Tag 9App-Entwickler · Team
Reichen Sie den freigegebenen Build und die Release Notes bei beiden Stores ein, stellen Sie das Release auf manuell oder gestaffelt und notieren Sie das Einreichungsdatum.
Checkliste
- Im App Store eingereicht
- Bei Google Play eingereicht
- Release auf manuell oder gestaffelt gestellt
Auszufüllende Felder
- Eingereicht am (Pflichtfeld)
- 9
Ergebnis der Prüfung bearbeiten
Tag 9 bis 12App-Entwickler · Team
Halten Sie das Ergebnis jeder Store-Prüfung fest. Lehnt ein Store den Build ab, markieren Sie die Ausführung als blockiert, notieren Sie den Grund und reichen Sie nach der Korrektur neu ein.
Auszufüllende Felder
- Ergebnis der Prüfung im App Store (Pflichtfeld)
- Ergebnis der Prüfung bei Google Play (Pflichtfeld)
- Ablehnungsgrund
- 10
Veröffentlichen und prüfen, ob die Version live ist
Woche 2Projektmanager · Team
Veröffentlichen Sie die Version am vereinbarten Tag, prüfen Sie, ob sie sich aus beiden Stores installieren lässt, und informieren Sie den Kunden.
Checkliste
- In beiden Stores live
- Installiert und startet aus dem Store
- Absturzberichte nach dem Release geprüft
- Kunde informiert
Auszufüllende Felder
- Live seit (Pflichtfeld)
Fertig, wenn
Die Version ist in beiden App Stores unter den eigenen Entwicklerkonten des Kunden live, und das Release ist in der Ausführung dokumentiert.
Passen Sie sie an. Benennen Sie Schritte um, ändern Sie Verantwortliche und ergänzen Sie Checklistenpunkte, Felder oder Freigaben. Die Vorlage ist ein Ausgangspunkt für die Arbeitsweise Ihres Teams.
Die KI-Agenten in dieser Vorlage
Ein Agent arbeitet nur an seinen eigenen Schritten, und jemand aus Ihrem Team prüft, was er getan hat. Alles, was ein Agent in eine verbundene App schreibt, wartet auf Freigabe, sofern Sie es nicht ausdrücklich erlauben.
Store-Notes-Autor
Entwirft die Release Notes für beide App Stores aus den Änderungen dieser Version.
Was er tut
- Liest die Features, die der Kunde hervorheben will, und die bekannten Probleme
- Schreibt kurze Release Notes für Nutzer
- Hält die Längengrenzen aus seinen Anweisungen ein
- Schließt seinen Schritt ab, damit der Engineering Lead prüfen kann
Geprüft von: Der Engineering Lead korrigiert die Notes und gibt den Build in Schritt 6 frei.
Fragen, die diese Vorlage beantwortet
Veröffentlichen Sie unter den eigenen Entwicklerkonten des Kunden mit eingeladenem Team, und reichen Sie nur einen getesteten und freigegebenen Build ein. In Schritt 2 lädt der Kunde das Team ein und beantwortet die Datenschutzfragen über den öffentlichen Link, und in Schritt 8 reicht der App-Entwickler den freigegebenen Build ein.
Ins Konto des Kunden, damit er App, Bewertungen und Nutzer behält, falls Sie sich einmal trennen. Schritt 2 bittet den Kunden, seine eigenen Konten zu bestätigen und Ihr Team einzuladen, bevor der erste Build für ein Release entsteht.
Testen Sie auf dem ältesten unterstützten Betriebssystem, testen Sie das Update von der Live-Version und prüfen Sie die Store-Richtlinien, die zu Ablehnungen führen. Schritt 4 enthält diese Checkliste für den QA Engineer, mit einem Link zum Testbericht.
Notieren Sie den Grund, beheben Sie ihn und reichen Sie neu ein, und informieren Sie den Kunden, statt den Release-Termin still verstreichen zu lassen. In Schritt 9 markiert der App-Entwickler die Ausführung mit dem Ablehnungsgrund als blockiert, bis der korrigierte Build neu eingereicht ist.
Lassen Sie KI die Release Notes für beide Stores aus den Änderungen der Version entwerfen, und lassen Sie die Freigabe des Builds bei Ihrem Team. Der Store-Notes-Autor entwirft den Text in Schritt 5, und Schritt 6 ist eine Freigabeprüfung, in der der Engineering Lead ihn korrigiert und den Build freigibt.
Reichen Sie früh ein, stellen Sie das Release auf manuell oder gestaffelt, und veröffentlichen Sie an dem Tag, den der Kunde vereinbart hat. In Schritt 7 legt der Kunde den Release-Termin fest, in Schritt 8 reicht der App-Entwickler mit manuellem oder gestaffeltem Release ein, und in Schritt 10 geht die Version live.
Führen Sie diesen Workflow in OKiDO aus
Richten Sie Schritte, Verantwortliche und Freigaben einmal ein und starten Sie dann für jeden neuen Fall eine Ausführung.