Studio · Landschaften und Transport
Entwicklung, QS, Produktiv. Und ein Weg dazwischen.
Die Wahrheit über die meisten Web-Werkzeuge: Es gibt genau ein System, und das ist das produktive. „Testumgebung" heißt dort, dass man vorsichtig ist. „Vorschau" heißt, dass man den Atem anhält. Und „Rollout" heißt, dass jemand am Freitagabend Dateien kopiert und am Montag herausfindet, welche er vergessen hat. Hier ist eine Landschaft ein bis drei Systeme mit festen Aufgaben: Entwicklung, QS, Produktiv – und der Weg dazwischen ist ein Transport mit Prüfbericht.
01 — Die Landschaft
Ein System, zwei Systeme, drei Systeme. Deine Entscheidung.
Ein System, wenn Geschwindigkeit zählt und der Auftritt klein ist: was gebaut wird, ist sofort produktiv. Zwei, wenn niemand mehr in Produktiv arbeiten soll. Drei, wenn zwischen Bauen und Freigeben jemand prüft, der es nicht selbst gebaut hat. Wir schreiben dir nicht vor, wie viele Systeme du brauchst – aber du kannst es werden, ohne das Werkzeug zu wechseln.
- Jedes System ist eine eigene Instanz mit eigener Adresse – nicht ein Schalter in derselben Datenbank
- Die Kette ist gerichtet: A nach B nach C. Wer von Entwicklung direkt nach Produktiv springt, überspringt die QS – und merkt es dort, wo es teuer ist
- Der Stand eines Features ist je System ablesbar: liegt hier, war hier, noch nicht hier
02 — Freitag, 17 Uhr
Der Unterschied zeigt sich nicht beim Bauen. Er zeigt sich beim Ausrollen.
Von Hand
Eine Liste in einer Mail: vier Seiten, zwei Vorlagen, ein Bild, ein neues Feld. Jemand arbeitet sie ab, in der Reihenfolge, in der sie dasteht. Das neue Feld kommt zuletzt, weil es zuletzt in der Mail steht – und die Seite davor ist zehn Minuten lang kaputt. Das Bild vergisst er, weil es nicht in der Sitzung entstand, sondern in einem Chat. Am Montag fragt jemand, warum das Logo fehlt, und niemand weiß, was noch fehlt.
Als Transport
Dieselben acht Objekte, gebündelt als Feature, festgeschrieben und ausgeführt. Der Server sortiert selbst: erst die Entität, dann das Feld, dann die Vorlage, dann die Seite. Vorher steht im Prüfbericht, was mitgeht, was fehlt und was überschrieben wird. Hinterher hat jedes Objekt eine Zeile im Protokoll. Was fehlt, fehlt sichtbar – und nicht erst am Montag.
03 — Das Feature
Änderungen wandern als Paket. Nicht als Liste in einer Mail.
Ein Feature bündelt, was fachlich zusammengehört: Seiten, Vorlagen, Dateien, Entitäten, Felder, Plugins. Es entsteht aus den Sitzungen, in denen gearbeitet wurde – du musst hinterher nicht rekonstruieren, was du angefasst hast, weil es mitgeschrieben wurde. Genau diese Rekonstruktion ist der Schritt, an dem es sonst schiefgeht.
- Die Liste ist zuerst eine Momentaufnahme und wächst mit jeder weiteren Sitzung
- Das Schnüren schreibt sie fest; danach lässt sich einzelnes ausnehmen
- Kommen nach dem Schnüren Änderungen dazu, sagt die Seite es – sonst würde ein alter Stand transportiert
- Objekte lassen sich auch von Hand aufnehmen, wenn etwas außerhalb einer Sitzung entstanden ist
04 — Abhängigkeiten
Die Reihenfolge ist der halbe Transport.
Eine Seite, die eine Vorlage benutzt, die es im Ziel noch nicht gibt, ist im Ziel kaputt. Deshalb prüft der Transport vorher, was woran hängt, und bringt die Objekte in eine Reihenfolge, in der jedes seinen Unterbau vorfindet: erst die Entität, dann das Feld, dann die Vorlage, dann die Seite.
- Prüfbericht vor dem Transport: was geht mit, was fehlt, was wird überschrieben
- Jedes Objekt bekommt im Protokoll eine eigene Zeile mit Ergebnis und Meldung
- Sprachvarianten wandern mit ihrem Original – nicht getrennt und nicht hinterher
- Ein erneuter Transport in dasselbe System ist möglich, wenn nachgebessert wurde
05 — Das Tor
Offene Prüfschritte halten die Kette an. Das ist der Sinn eines Tors.
Nach einem Transport entsteht ein Prüfplan für das Zielsystem: einzelne Schritte mit erwartetem Ergebnis. Solange Fälle offen oder gefallen sind, geht es nicht weiter – und der Knopf sagt warum, statt einen Aufruf anzubieten, der scheitert.
- Drei Ergebnisse je Fall: bestanden, gefallen, entfällt – „gemacht" ist keines davon
- Bei gefallen und entfällt verlangt der Server einen Befund. Ein Haken ohne Begründung ist keine Prüfung, sondern eine Behauptung mit Zeitstempel
- Nach einer Nacharbeit entsteht ein neuer Plan; die alten bleiben als Beleg stehen
- Der Prüfplan lässt sich vom Assistenten schreiben – aus dem, was das Feature enthält
06 — Was fehlt
Was der Transport heute nicht mitnimmt.
Struktur wandert, Inhalt nicht. Seiten, Vorlagen, Dateien, Entitäten und Felder fahren mit – die Zeilen darin bleiben, wo sie sind. Wer einen Katalog in zwei Systemen gleich halten will, pflegt ihn heute in beiden. Das ist keine Feinheit im Kleingedruckten, sondern der Satz, an den man sich erinnern sollte, wenn in Produktiv plötzlich Preise fehlen.
Es gibt Versionierung je Objekt, aber keinen Knopf „ganzes Feature zurück". Wer zurück muss, holt die vorherige Fassung der betroffenen Objekte – einzeln, von Hand, und mit der Objektliste als Gedächtnisstütze.
Wenn zwei Systeme dasselbe Objekt geändert haben, gewinnt der Transport. Deshalb Objektsperren – und deshalb wird in Produktiv nicht gebaut.
Weiter im Studio
Und wer schreibt auf, was da eigentlich gebaut wurde?
Die Assistenten. Während sie es bauen – also zu dem einzigen Zeitpunkt, an dem noch jemand die Gründe kennt.