Mit einer einzigen Anwendung beginnen, die wirklich zählt

Du hast eine Liste von allem, was dein Team betreut. Anwendungen, Datenbanken, Infrastrukturkomponenten, Skripte, Cron-Jobs. Vielleicht hast du eine Woche für ein Inventar gebraucht, oder du hast es während eines Meetings auf ein Whiteboard gekritzelt. Jetzt starrst du auf diese Liste, und die Frage drängt sich auf: Wo fangen wir an?

Hier erstarren die meisten Teams. Sie haben Angst, das Falsche auszuwählen. Sie haben Angst, etwas Wichtigeres zu übersehen. Sie haben Angst, dass ihre Wahl keine sichtbaren Ergebnisse bringt. Also analysieren sie weiter, diskutieren weiter und verschieben das Handeln immer weiter.

Der Trick ist nicht, den perfekten Startpunkt zu wählen. Der Trick ist, etwas zu wählen, das eine hohe Erfolgswahrscheinlichkeit hat und dessen Erfolg auch bemerkt wird.

Mit einer Anwendung beginnen, nicht mit Infrastruktur oder Datenbank

Es ist verlockend, mit der Infrastruktur zu beginnen, weil sie sich grundlegend anfühlt. Oder mit der Datenbank, weil Datenbankänderungen beängstigend sind. Aber der beste Startpunkt ist eine Anwendung.

Das liegt nicht daran, dass Anwendungen wichtiger sind. Sondern daran, dass sie sich am häufigsten ändern und diese Änderungen für die Nutzer am sichtbarsten sind. Wenn du eine Pipeline für eine Anwendung baust, sind die Ergebnisse sofort spürbar. Builds werden automatisch. Tests laufen bei jeder Änderung. Deployments sind keine manuellen Rituale mehr, die um 22 Uhr drei Leute in einer Videokonferenz erfordern.

Diese Erfahrung schafft Vertrauen. Du siehst, wie die Pipeline funktioniert. Du siehst, wie das Team beginnt, ihr zu vertrauen. Und dieses Vertrauen brauchst du, bevor du dich an die schwierigeren Teile wie Datenbankmigrationen oder Infrastruktur-Provisionierung wagst.

Drei Kriterien für die Wahl der richtigen Anwendung

Sieh dir dein Inventar an und wähle eine Anwendung aus, die alle drei Bedingungen erfüllt.

Das folgende Flussdiagramm veranschaulicht die drei Kriterien, um dir bei der Entscheidung zu helfen:

flowchart TD A[Start: Alle Anwendungen auflisten] --> B{Aktiv entwickelt?} B -- Nein --> C[Diese Anwendung überspringen] B -- Ja --> D{Echte Nutzer?} D -- Nein --> C D -- Ja --> E{Team zur Zusammenarbeit bereit?} E -- Nein --> C E -- Ja --> F[Diese Anwendung auswählen] F --> G[Golden-Path-Pipeline bauen] G --> H[Auf andere Anwendungen ausweiten]

Erstens: Die Anwendung wird aktiv entwickelt oder häufig geändert. Eine Anwendung, die niemand anfasst, bringt dir nichts. Du brauchst echte Änderungen, die durch die Pipeline fließen, um die echten Probleme zu finden. Wenn die Anwendung nur alle paar Monate aktualisiert wird, verbringst du mehr Zeit mit Warten als mit Lernen.

Zweitens: Die Anwendung hat echte Nutzer. Kein Prototyp. Kein Proof-of-Concept, der auf einem Laptop läuft. Echte Nutzer bedeuten echte Auswirkungen. Wenn die Pipeline funktioniert, erhalten Nutzer schneller Updates. Wenn die Pipeline einen Fehler vor dem Deployment abfängt, erleben die Nutzer keinen Ausfall. Das Team spürt den Unterschied, und dieses Gefühl verkauft die nächste Phase der Arbeit an die Stakeholder.

Drittens: Das Team, das die Anwendung betreut, ist zur Zusammenarbeit bereit. Dies ist das wichtigste Kriterium. Du kannst den besten technischen Plan der Welt haben, aber wenn das Team überlastet, ausgebrannt oder einfach nicht interessiert ist, wird die Pipeline nicht halten. Finde ein Team, das etwas Kapazität und Neugier hat. Arbeite mit ihnen zusammen. Zwinge einem bereits kämpfenden Team keinen neuen Prozess auf.

Triff die Entscheidung schnell

Der Auswahlprozess sollte ein oder zwei Diskussionsrunden dauern. Sammle das Inventar. Schau, welche Anwendungen sich am häufigsten ändern. Sprich mit den Teams. Frage, ob sie Raum haben, etwas Neues auszuprobieren. Dann entscheide.

Lass dich nicht über Wochen hinziehen. Analyse-Paralyse ist der Feind des Fortschritts. Es ist besser, einen vernünftigen Kandidaten auszuwählen und mit dem Bauen zu beginnen, als einen Monat lang jede Option zu analysieren und am Ende nichts zu haben.

Diese Anwendung wird dein Golden Path

Sobald du die Anwendung ausgewählt hast, wird sie zu deinem Golden Path. Dies ist der Begriff für die erste standardisierte Auslieferungspipeline, die dein Team dokumentiert, baut und als Referenz für alles andere behandelt.

Jede Entscheidung über Pipelines, Tests und Deployment wird hier zuerst angewendet. Wie strukturierst du das Build-Skript? Welche Tests laufen in CI? Wie gehst du mit Secrets um? Wie deployst du in Staging vs. Produktion? All diese Fragen werden für diese eine Anwendung beantwortet.

Wenn der Golden Path gut läuft, hast du eine funktionierende Vorlage. Die nächste Anwendung kann dem gleichen Muster folgen. Dann die nächste. Dann kannst du das Muster für Datenbankänderungen anpassen. Dann für die Infrastruktur. Jeder Schritt wird einfacher, weil du nicht bei Null anfängst.

Der Golden Path ist nichts Besonderes

Es ist wichtig zu verstehen, was der Golden Path nicht ist. Er ist keine Aussage, dass diese Anwendung wichtiger ist als andere. Er ist kein dauerhaftes Privileg. Er ist ein bewusstes Experiment, das das geringste Risiko und die höchste Erfolgswahrscheinlichkeit haben soll.

Wenn etwas schiefgeht, ist der Schaden auf eine Anwendung begrenzt. Wenn sich eine Entscheidung als falsch erweist, korrigierst du sie für eine Anwendung und lernst daraus. Die Lehren gelten dann für alles andere.

Betrachte es als Testumgebung. Du testest die Fähigkeit deines Teams, eine Pipeline zu bauen, deine Annahmen über Automatisierung zu überprüfen und zu beweisen, dass der Ansatz funktioniert, bevor du ihn skalierst.

Alle auf den gleichen Stand bringen

Bevor du eine einzige Zeile Pipeline-Code schreibst, stelle sicher, dass jeder weiß, welche Anwendung der Golden Path ist und warum sie ausgewählt wurde. Diese Übereinkunft verhindert spätere Verwirrung. Wenn jemand fragt, warum eine andere Anwendung noch nicht angefasst wurde, ist die Antwort klar: Wir beweisen das Muster zuerst an dieser einen und wenden es dann auf den Rest an.

Schreibe es auf. Platziere es sichtbar. Erwähne es im Daily. Das Ziel ist nicht, Bürokratie zu schaffen. Das Ziel ist, zu vermeiden, dass die Frage "Warum arbeiten wir an dem und nicht an jenem?" den Schwung ausbremst.

Praktische Checkliste vor dem Start

  • Eine Anwendung ist ausgewählt, die aktiv entwickelt wird, echte Nutzer hat und ein bereitwilliges Team besitzt
  • Die Entscheidung ist dokumentiert und mit dem Team geteilt
  • Jeder versteht, dass dies der Golden Path ist, keine dauerhafte Priorität
  • Das Team, das die Anwendung betreut, hat der Zusammenarbeit zugestimmt
  • Ein grober Zeitplan für die erste funktionierende Pipeline ist festgelegt (nicht perfekt, nur funktionierend)

Die konkrete Erkenntnis

Wähle eine Anwendung aus, die sich häufig ändert, echte Nutzer hat und ein Team, das mit dir zusammenarbeiten möchte. Baue zuerst die Pipeline für diese Anwendung. Bring sie zum Laufen. Lerne daraus. Dann mach es für die nächste. So gelangst du von einer Liste all deiner Besitztümer zu einem Auslieferungssystem, das tatsächlich ausliefert.