Elf Produkte, ein Produktionssystem, und die Reihenfolge, in der wir Belege lesen

Ein Studio dieser Größe kann elf Produkte nicht tragen, indem es elf Launches durchführt. Es trägt sie, weil die Teile eines Launches, die jedes Mal identisch sind — Store-Material, Release-Checklisten, Abo-Infrastruktur, Screen-Captures, Datenschutzdokumente, die Veröffentlichungspipeline selbst — einmal in einem System erledigt werden statt einmal pro Produkt von Hand.

Soweit die offensichtliche Hälfte, und das ist nicht die interessante. Infrastruktur zu teilen ist ein gut verstandener Handel. Der Teil, der immer wieder schiefgeht, ist zu wissen, was über ein Produkt stimmt, das man vor drei Wochen ausgeliefert hat.

Zwei Regeln, die Automatisierung neustartbar machen

Arbeit im System wird über einen deterministischen Hash ihrer eigenen Eingaben identifiziert. Ein doppelter Auslöser, ein Retry oder ein Absturz mit Neustart lösen sich alle zur gleichen Identität auf, also kann das System nicht doppelt rendern oder doppelt posten. Diese eine Eigenschaft macht Wiederholen sicher, und sicher wiederholen zu können ist der Unterschied zwischen einer Automatisierung, die man laufen lassen kann, und einer, die jemand bewachen muss.

Die zweite Regel: Veröffentlichen sitzt hinter einem Menschen. Nicht weil die Automatisierung unfertig wäre — weil die Kosten einer falschen Veröffentlichung asymmetrisch sind, und ein Tor, das nie gebraucht wird, ist billig, während ein Tor, das einmal fehlt, es nicht ist. Aus diesem Studio ist nichts hinausgegangen, ohne dass jemand es gesagt hat.

Der Ausfall, der kein Fehler ist

Am 30. September gingen zwei Produkte im App Store live. Diese Website sagte, eines davon sei in der Beta und auf keinem der beiden Stores öffentlich eingetragen. In diesem Repository war nichts falsch, und kein Review hätte es finden können — denn ein Launch ist ein Ereignis außerhalb des Repositorys: keine Datei ändert sich, also gibt es kein Diff zu lesen und keinen Test, der scheitern kann.

Das ist das ganze Argument für ein Tor vor dem Deployment statt für eine Gewohnheit. Ein Skript fragt Apple nach jedem Bundle-Identifier, listet jede App im Entwicklerkonto auf und fordert bei Google Play jede Paketseite an. Es läuft vor einem Deploy, nicht wenn etwas seltsam aussieht — denn bis etwas seltsam aussieht, hat es drei Tage gut ausgesehen.

Welchem Dokument glauben

Derselbe Fehler ist in diesem Studio inzwischen siebenmal passiert, und nur einer davon war Unachtsamkeit. Die anderen sechs hatten alle dieselbe Form: eine Behauptung aus dem Erzähldokument eines Projekts übernommen, während maschinenlesbare Belege im selben Ordner lagen, neuer, und etwas anderes sagten.

Veyra ist das durchgearbeitete Beispiel. Seine Seite auf dieser Website sagte, es sei nie eine Generierung gelaufen und nie Modellgewichte geladen worden. Das kam aus einem Statusdokument und einer Readme, beide vom 11. September, und wurde hier zwei Wochen lang wiederholt. Im selben Repository lag zur gleichen Zeit eine Datei, die von einem physischen Telefon gezogen worden war und zwei echte Generierungsläufe festhielt — je vier Kandidaten, jedes Bild in einer anderen Größe, mit dem echten Modell markiert, mit Zeiten, die aus der eigenen Datenbank des Geräts gelesen wurden. Die Seite hat ihr eigenes Produkt zwei Wochen lang untertrieben — ein freundlicherer Ausfall, als eines zu übertreiben, und immer noch eine falsche Seite.

Also ist die Reihenfolge aufgeschrieben, und ein niedrigerer Rang überstimmt nie einen höheren, wie neu er auch geschrieben und wie selbstsicher er formuliert ist:

• Authentifizierter Anbieterzustand — was der Store selbst sagt, angemeldet gelesen.
• Ausgelieferte Artefakte und maschinenlesbare Belege — die eigenen Metadaten eines Release-Builds, eine vom Gerät gezogene Datenbank, eine mitgeschnittene Antwort, ein Tag.
• Aktueller Quellcode und Konfiguration — die Dateien, die der Build tatsächlich lädt.
• Datierte Abnahmedokumente — Prosa, aber gegen einen Lauf geschrieben, der stattgefunden hat.
• Status- und Übergabe-Erzählung — eine Readme, eine Statusdatei, eine Übergabe.
• Planungsdokumente und Briefings — einschließlich des Briefings, das ein Produkt auf dieser Website eingeführt hat.

Die Rangfolge sagt nichts darüber, wer sorgfältig schreibt. Sie sagt etwas darüber, was verfällt. Ein Store-Eintrag ändert sich, wenn sich das Produkt ändert; eine Readme ändert sich, wenn jemand daran denkt.

Wofür ein geteiltes System eigentlich da ist

Jede Regel oben begann damit, dass bei einem Produkt etwas Bestimmtes schiefging, und jede davon lebt heute im geteilten System statt in der Kopie dieses einen Produkts. Das ist der eigentliche Zinseszins: nicht dass der fünfte Launch günstiger ist als der erste, obwohl er das ist, sondern dass der fünfte Launch die Fehler der ersten vier nicht wiederholen kann — weil der Fehler ein scheiternder Test an einer Stelle ist, die keinem der beiden Produkte gehört.