Novemade

Wie wir bauen

11 Produkte. Ein gemeinsames Produktionssystem.

11 Produkte laufen nicht nebeneinander, solange die teuren Teile nicht geteilt werden. Research, Produktion, Release und Messung laufen über ein internes System, sodass das fünfte Produkt weniger kostet als das erste und beim Start besser informiert ist.

Die Schleife

9 Stufen, und die letzte speist die erste.

Jedes Produkt läuft denselben Kreis. Die Stufen sind nach dem benannt, was in ihnen passiert — deshalb sind etwas zu lernen und danach zu handeln zwei Stufen und nicht eine.

  1. 01ResearchSignale und eine Ideenbank pro Produkt, auf Relevanz bewertet, bevor etwas gemacht wird.
  2. 02DesignDas Produkt entscheidet über seine Stimme, seine Aussagen und seine Grenzen. Das System füllt sie aus.
  3. 03BauenAssets, Sprechertext und Untertitel, zusammengesetzt aus dem eigenen Material jedes Produkts.
  4. 04LokalisierenJeder String in jeder Sprache, wobei die Gleichheit der Kataloge geprüft und nicht angenommen wird.
  5. 05TestenAutomatische Prüfungen, dann ein Mensch. Nichts erreicht eine Warteschlange ungeprüft.
  6. 06VeröffentlichenVerpackung pro Plattform, wobei das Veröffentlichen absichtlich hinter einer Freigabe durch Menschen bleibt.
  7. 07MessenRelease- und Performance-Signale laufen dorthin zurück, wo die Arbeit entstand.
  8. 08LernenWas bei einem Produkt funktioniert hat, ist für das nächste lesbar, das danach fragt.
  9. 09VerbessernDie Korrektur landet im gemeinsamen System, nicht in der Kopie eines Produkts.

Was das System garantiert

Automatisierung ist nur nützlich, wenn sie sicher wiederholbar ist.

Der meiste Aufwand in einem Produktionssystem besteht nicht darin, Dinge herzustellen. Er besteht darin, sicherzustellen, dass ein Retry, ein Absturz oder ein doppelter Auslöser keinen Schaden anrichten kann — und genau das erlaubt es, den Rest automatisch laufen zu lassen.

Nichts wird zweimal veröffentlicht

Inhalts- und Publish-Jobs werden über deterministische Hashes ihrer eigenen Eingaben identifiziert. Ein doppelter Auslöser, ein Retry oder ein Absturz mit Neustart löst zur selben Identität auf, sodass das System nicht doppelt rendern oder doppelt posten kann.

Ein Retry ist immer sicher, und genau das macht Automatisierung neustartfähig.

Ein Absturz setzt fort, er startet nicht neu

Jede Stufe sichert ihr Ergebnis, bevor die nächste beginnt. Ein Fehler auf halber Strecke knüpft an die letzte abgeschlossene Stufe an, statt die teure Arbeit dahinter zu wiederholen.

Eine lange Pipeline kann scheitern, ohne den ganzen Durchlauf zu kosten.

Das System lernt nie den Namen eines Produkts

Alles, was pro Produkt variiert — Stimme, Inhaltsfamilien, Speicherorte von Assets, Regeln darüber, was nie behauptet werden darf — liegt in der Konfiguration dieses Produkts. Der gemeinsame Code liest sie und verweist nie direkt auf ein Produkt.

Ein neues Produkt ist eine Konfiguration, kein Fork.

Wiederholung wird gemessen, nicht gehofft

Jedes Stück trägt einen Fingerabdruck seines Themas, seines Aufhängers und seines Skripts. Neue Arbeit wird mit der jüngeren Geschichte dieses Produkts verglichen und abgelehnt, wenn sie zu nah dran ist — was den Generator für einen anderen Blickwinkel zurückschickt.

Menge, ohne einen Feed, der klingt wie ein Produkt im Selbstgespräch.

Fehler werden klassifiziert, nicht verschluckt

Externe Aufrufe werden mit begrenztem Backoff wiederholt und in vorübergehend, dauerhaft und nicht konfiguriert einsortiert. Eine Plattform, die noch nicht eingerichtet ist, ist eine normale Warnung, nie ein Absturz und nie ein stilles Überspringen.

Der Unterschied zwischen kaputt und noch nicht verbunden ist immer sichtbar.

Qualitätsprüfungen laufen, bevor ein Mensch hinsieht

Erzeugte Ausgaben werden automatisch geprüft, bevor sie eine Warteschlange erreichen — auch darauf, ob jede Szene echtes Produktmaterial statt eines Platzhalters benutzt hat. Was ein Mensch prüft, hat die mechanischen Tests bereits bestanden.

Prüfzeit geht in Urteilsvermögen, nicht ins Aufspüren offensichtlicher Fehler.

Bugs werden Tests, nicht Folklore

Die unangenehmen Fehler — eine Vorlage, die ein Thema verstümmelt, das schon als Frage formuliert war, ein Einstieg, der ein Präfix verdoppelt — wurden jeweils gefunden, indem echte Ausgaben erzeugt und gelesen wurden, und dann mit einem Regressionstest festgenagelt.

Dieselbe Fehlerklasse kann nicht still zurückkommen.

Eine Sprache wird ganz ausgeliefert oder nicht angeboten

Kataloge werden gegen die Referenzsprache auf Gleichheit geprüft, bevor ein Build durchgeht, sodass eine Sprachfassung nicht mit der Hälfte ihrer Keys und einem englischen Satz mitten im Bildschirm erscheinen kann. Wo eine Sprache mehr als Text braucht — ein Layout von rechts nach links, ein längeres Kompositum, eine aufgenommene Stimme — wird auch das geprüft, auf dem Bildschirm und nicht in der Datei.

Zehn, sechzehn oder neunundzwanzig Sprachen, und in keiner ein halb übersetzter Bildschirm.

Jedes erzeugte Asset weiss, was es gemacht hat

Von einem Modell erzeugte Assets tragen das Modell, seine genaue Revision, seine Lizenz und die Kandidatenmenge, aus der sie gewählt wurden, gespeichert neben der Datei. Aufgenommenes Audio trägt seine Engine, seine Lizenz und die Messgrösse, auf die seine eigene QA es bewertet hat. Ein Satz Screenshots trägt einen Hash pro Datei.

Eine Lizenzfrage Jahre später ist eine Abfrage, keine Ermittlung.

Die Freigabe durch Menschen bleibt im Ablauf

Das System bereitet vor, verpackt und schlägt vor. Ein Mensch gibt frei. Veröffentlichen ist nie vollständig autonom — durch Entwurf, nicht durch Versäumnis.

Skalierung, ohne die redaktionelle Kontrolle abzugeben.

Prüfen Sie es selbst

Diese Website ist mit derselben Disziplin gebaut

Statt den Standard zu beschreiben, hier das, was auf der Seite erzwungen wird, die Sie gerade lesen.

  • 01Eine Markendefinition erzeugt jedes auslieferbare Zeichen, Icon, Favicon und Social-Card. Nichts wird von Hand exportiert.
  • 02Die Asset-Pipeline verweigert einen Screenshot ohne Bildunterschrift, sodass kein Bild ohne Alternativtext ausgeliefert werden kann.
  • 03Der Build scheitert, wenn ein Produkt einen Store-Eintrag behauptet, den es nicht hat, oder wenn irgendwo im Inhalt eine Downloadzahl, Bewertung oder Nutzerzahl auftaucht.
  • 04Der Farbkontrast wird in einem Test gegen jede Fläche berechnet, auf die er gemalt wird, in beiden Designs.
  • 05Ein Browser-Harness lädt jede Route in acht Breiten und scheitert bei horizontalem Überlauf, bei einem zusammengebrochenen Mobilmenü und bei einem Menü, das sich nicht schliessen lässt.
  • 06Interne Links werden bei jeder Prüfung gecrawlt, sodass eine Umbenennung keinen toten Link hinterlassen kann.
  • 07Jede Zahl, die diese Seite über ihren eigenen Katalog nennt, wird beim Build aus dem Katalog berechnet. Ein Test lässt den Build scheitern, wenn eine von Hand in einen Satz geschrieben wird.
  • 08Jedes Produkt muss eine funktionierende Demo haben, und das wird geprüft statt angenommen — ein Produkt ohne Demo hinzuzufügen lässt den Build scheitern.
  • 09Ein Produkt darf nur dann als verfügbar markiert werden, wenn sein Store-Status sagt, dass ein Eintrag öffentlich ist, und nur ein öffentlicher Eintrag darf einen Download-Button erzeugen.

Die Grenze

Was wir nicht veröffentlichen

Diese Seite beschreibt, was das System tut und was es produziert. Sie beschreibt nicht, wie es betrieben wird. Hosts, Endpunkte, Zugangsdaten, Maschinennamen, Speicherpfade und Sicherheitsarchitektur bleiben privat — nicht weil sie interessant wären, sondern weil es nachlässig wäre, sie zu veröffentlichen. Die öffentliche Seite und die internen Systeme teilen keine Zugangsdaten und keinen Steuerungsweg.