Entwicklungs-, Test- und Produktionsumgebungen

Entwicklungs-, Test- und Produktionsumgebungen

0:00 n8n verbindet seine Instanzen über Git, und damit steht Ihnen eine Technik zur Verfügung, die Sie aus der Softwareentwicklung kennen. Mit einem Unterschied, den die Dokumentation ungewöhnlich deutlich benennt: Push und Pull auf derselben Instanz ist zwar möglich, wird aber ausdrücklich nicht empfohlen. Der Grund ist einfach — dort entstehen Konflikte und überschriebene Arbeit. Man könnte sagen: Es ist technisch erlaubt und organisatorisch eine Verabredung zum Datenverlust.

0:27 Dieses Modul zeigt, wie man es stattdessen aufbaut, und was passiert, wenn doch etwas schiefgeht.

Entwicklungs-, Test- und Produktionsumgebungen

0:33 Der sechste und letzte Tag. Heute geht es um Betrieb. Wir beginnen mit Umgebungen und der Versionsverwaltung. Danach die Entscheidung zwischen Cloud und Self-Hosting samt Installation und Sicherung. Dann Skalierung und Monitoring. Und zum Abschluss das Projekt, in dem alles zusammenkommt. Wenn Sie die letzten fünf Tage mitgegangen sind, haben Sie heute vor allem eine Aufgabe: das Gebaute so aufzustellen, dass es jemand anders übernehmen kann.

Warum getrennte Umgebungen

1:01 Fangen wir mit der Begründung an. Auf der Produktionsinstanz zu entwickeln heißt, im Betrieb zu proben — und wie bei jeder Probe im laufenden Betrieb merkt das Publikum es irgendwann. Vier Dinge, und alle sind Ihnen in diesem Seminar schon begegnet. Ein Testlauf löst echte Aufrufe in angebundenen Systemen aus — die Testbestellung beim Lieferanten aus Modul zehn.

1:22 Eine halbfertige Änderung wird versehentlich veröffentlicht. Zwei Personen wollen ändern, und eine bekommt nur Lesezugriff; das ist die Schreibsperre aus Modul zwei, die im Team plötzlich hinderlich wird. Und der vierte ist der unangenehmste: Ein fehlerhafter Baustein hindert die Instanz am Start — mitsamt allem anderen, was darauf läuft.

1:43 n8n bildet Umgebungen über git-basierte Versionsverwaltung ab: Instanzen werden mit einem Repository verbunden, und Branches tragen die Umgebungen. Das ist eine elegante Lösung, weil sie ein bewährtes Werkzeug nutzt statt ein eigenes zu erfinden — Ihre Workflows liegen als Dateien im Git und lassen sich dort vergleichen, prüfen und freigeben.

2:03 Zwei Voraussetzungen müssen Sie kennen: Verfügbar ist das in den Plänen Business und Enterprise, und einrichten darf es nur, wer Instanzeigentümer oder Instanz-Admin ist. Das ist also keine Funktion, die man nebenbei aktiviert. Zwei Zeilen, und die zweite ist die interessante. Instanzeigentümer und Instanz-Admins dürfen einrichten, pushen und pullen. Project Admins dürfen pushen, aber nicht pullen.

2:27 Warum diese Asymmetrie? Weil die beiden Richtungen unterschiedlich gefährlich sind. Pushen heißt: Ich gebe meinen Stand nach Git — im schlimmsten Fall steht dort Unsinn, den man nicht übernimmt. Pullen heißt: Ich überschreibe den Stand dieser Instanz mit dem aus Git. Das ist die Richtung, in der Arbeit verloren geht, und deshalb ist sie enger vergeben.

2:49 Die Fußzeile sagt es deutlich. Der erste Punkt ist der Normalzustand in vielen Häusern: Es gibt nur eine Instanz, und die Testumgebung ist ein Ordner darin. Das ist keine Trennung, das ist eine Beschriftung. Der zweite ist eine Frage der Disziplin: Die Trennung ist eingerichtet, aber alle arbeiten trotzdem in Produktion — weil dort die echten Daten liegen.

3:11 Der dritte macht jeden Test wertlos: Die Umgebungen laufen auf unterschiedlichen n8n-Versionen. Und der vierte ist die Grundvoraussetzung: Umgebungen werden geplant, ohne den Plan dafür zu haben.

Source Control auf Git-Basis

3:23 Jetzt zur Einrichtung. n8n lässt Ihnen dabei viele Freiheiten — und genau deshalb lohnt es sich, die vier Muster zu kennen und eines bewusst zu wählen. Vier Kombinationen aus Instanzen und Branches. Mehrere Instanzen mit mehreren Branches ist die echte Umgebungstrennung: Sie pushen aus der Entwicklung, machen einen Pull Request und pullen in die Produktion.

3:45 Mehr Schritte, dafür eine zusätzliche Sicherung. Mehrere Instanzen mit einem Branch bedeutet: überall dasselbe — sehr praktisch, um eine neue n8n-Version zu testen, während die Produktion auf der alten bleibt. Eine Instanz mit mehreren Branches ist die Review-Instanz, die zwischen Ständen wechselt. Und eine Instanz mit einem Branch ist der einfachste Fall.

4:07 Achten Sie auf die Fußzeile: Beim Branch-Wechsel räumt n8n nichts auf. Vier Punkte, und zusammen sind sie die Kernaussage dieses Kapitels. Technisch ist Push und Pull auf derselben Instanz möglich. n8n empfiehlt es ausdrücklich nicht. Sonst entstehen Merge-Konflikte und überschriebene Arbeit. Und die Empfehlung lautet: Der Vorgang sollte in eine Richtung laufen — zu Git oder von Git.

4:31 Ich finde diese Klarheit bemerkenswert, denn Hersteller schreiben selten in ihre Dokumentation, dass man eine Funktion besser nicht so benutzt. Wenn sie es tun, lohnt das Zuhören. Vier Punkte zum gefährlicheren der beiden Wege. Der Pull kann lokale Arbeit überschreiben; n8n warnt und fragt nach — lesen Sie diese Nachfrage wirklich.

4:52 Neue Variablen und Credentials kommen als Platzhalter und müssen gefüllt werden; das ist gewollt, denn Geheimnisse gehören nicht ins Git. Gelöschte Ressourcen verschwinden nicht automatisch — n8n fragt, ob Sie sie ebenfalls entfernen möchten. Und der vierte überrascht im Alltag: Eigentümer von Workflows und Credentials können sich beim Pull ändern, weil n8n versucht, sie passenden Benutzern und Projekten zuzuordnen.

5:18 Der erste Punkt ist die verbotene Kombination: Gearbeitet wird auf der Instanz und gleichzeitig im Repository. Der zweite ist der häufigste Fehler nach dem ersten Pull in einer neuen Umgebung: Die Credential-Platzhalter bleiben leer, und der erste Lauf scheitert — das ist harmlos, wenn man es erwartet, und verwirrend, wenn nicht.

5:36 Der dritte ist die Aufräum-Fußzeile von eben: Nach dem Branch-Wechsel liegen doppelte Workflows in der Instanz. Und der vierte ist ein Betriebsrisiko: Der Pull wird ausgeführt, während produktive Läufe unterwegs sind.

Freigabe und Auslieferung

5:49 Jetzt der Weg einer Änderung von der Entwicklung in den Betrieb. Und hier zeigt sich der eigentliche Gewinn des ganzen Aufbaus: Der Pull Request ist die Sicherung, nicht die Bürokratie. Fünf Schritte. Bauen und testen Sie auf der Entwicklungsinstanz. Pushen Sie den Stand in den Entwicklungs-Branch. Überführen Sie ihn über einen Pull Request in den Produktions-Branch — das ist der Moment, in dem jemand anders hinsieht.

6:14 Pullen Sie auf der Produktionsinstanz und prüfen Sie die Platzhalter. Und veröffentlichen Sie dort — als eigene, bewusste Handlung. Beachten Sie, dass Pullen und Veröffentlichen zwei getrennte Schritte sind: Der Stand ist auf der Instanz, bevor er produktiv wirkt. Das ist eine zusätzliche Sicherheitsstufe, die man nutzen sollte.

6:34 Vier Eigenschaften dieses Aufbaus. Die Produktionsinstanz nimmt nur, was durch den Pull Request gekommen ist — es gibt keinen zweiten Weg hinein. Wer dort pullen darf, ist auf wenige Rollen begrenzt; die Tabelle vom Anfang des Moduls. Der Weg lässt sich über die n8n-API in eine Pipeline einbauen, wenn Sie das möchten. Und der vierte Punkt ist mir wichtig: Veröffentlichen bleibt eine Entscheidung, auch wenn der Rest automatisch läuft.

7:01 Automatisierung bis zur Instanz, Entscheidung beim Menschen — dasselbe Muster wie beim Human-in-the-Loop. Der erste Punkt hebelt das Vier-Augen-Prinzip aus: Der Pull Request wird von derselben Person gestellt und genehmigt. Das lässt sich in den meisten Git-Plattformen technisch verhindern — tun Sie es. Der zweite nimmt die letzte Sicherung heraus: Die Pipeline pullt und veröffentlicht in einem Schritt.

7:25 Der dritte ist ein Klassiker mit garantiertem Datenverlust: Auf der Produktionsinstanz wird nachgebessert, und der nächste Pull wirft es weg. Und der vierte ist ein blinder Fleck: Niemand prüft, ob die Umgebungsvariablen beider Instanzen zusammenpassen.

Wenn etwas schiefgeht

7:40 Zum Abschluss der Rückweg. Und die Regel dazu ist einfach: Er gehört geprobt, bevor er gebraucht wird. Ein Rückweg, den man zum ersten Mal im Ernstfall geht, ist kein Rückweg, sondern ein Experiment. Vier Wege in den Verlust. Zwei Personen ändern denselben Workflow in verschiedenen Umgebungen — das ist der klassische Konflikt.

8:01 Ein Pull überschreibt lokale Arbeit, die nicht gepusht war; deshalb die Nachfrage, die man lesen soll. Eine gelöschte Ressource bleibt lokal bestehen und wird beim nächsten Mal wieder gepusht — dann kommt sie zurück, und niemand versteht, warum. Und der vierte ist die Aufräum-Eigenheit: Der Branch wird gewechselt, und niemand räumt die Reste auf. Alle vier sind vermeidbar, wenn man sie kennt.

8:25 Fünf Schritte, und der dritte ist der, den fast niemand macht. Sichern Sie den letzten funktionierenden Stand als benannte Version — die Technik aus Modul zehn, hier als Rückversicherung. Prüfen Sie, dass er sich auf der Produktionsinstanz wiederherstellen lässt. Spielen Sie den Weg einmal ohne Ernstfall durch. Legen Sie fest, wer im Ernstfall entscheidet und wer ausführt — zwei Rollen, nicht eine.

8:48 Und legen Sie den Ablauf dort ab, wo er nachts gefunden wird; nicht im Werkzeug, das beim Ausfall womöglich mit ausgefallen ist. Vier Zutaten. Eine Testinstanz auf der neuen Version, verbunden mit demselben Branch — das ist übrigens genau das Muster aus der Tabelle, mehrere Instanzen an einem Branch. Die vorhandenen Testfälle, durchgefahren vor dem Umstieg. Den Migrationsbericht für den Sprung auf 2.x, über den wir im nächsten Modul sprechen.

9:16 Und einen festgelegten Zeitpunkt, an dem zurückgedreht wird. Dieser letzte Punkt ist eine Disziplinfrage: Ohne vorher festgelegtes Abbruchkriterium kämpft man sich durch, weil man schon so weit gekommen ist. Der erste Punkt ist die Rechnung für den ungeprobten Rückweg: Er scheitert am fehlenden Schlüssel — dem Verschlüsselungsschlüssel aus dem letzten Modul.

9:37 Der zweite ist ein alter Bekannter aus dem Betrieb: Aktualisiert wird freitagnachmittags. Der dritte ist eine halbe Vorbereitung: Der Migrationsbericht wird gelesen, aber die Befunde werden nicht abgearbeitet. Und der vierte ist die fehlende Disziplin von eben: Es gibt kein Abbruchkriterium, und der Umstieg zieht sich über Tage — mit einer Produktion, die zwischen zwei Ständen hängt.

Übung

10:00 Jetzt entwerfen Sie den Weg für Kesselwerk. Kein Aufbau diesmal, sondern ein Ablauf — und ein Konfliktfall, den Sie ausdrücklich durchspielen sollen. Kesselwerk betreibt künftig zwei Instanzen: eine für die Entwicklung, eine für die Produktion, verbunden mit je einem Branch. Das ist das erste Muster aus der Tabelle — die echte Umgebungstrennung. Die Änderung aus Modul zehn, die Einordnung nach Dringlichkeit, soll diesen Weg gehen.

10:26 Damit schließt sich ein Bogen: Sie haben diese Änderung am dritten Tag gebaut, getestet und freigeben lassen. Jetzt geht es darum, wie sie tatsächlich in Produktion kommt — und was passiert, wenn dabei etwas dazwischenkommt. Das Lernziel: Änderungen so zwischen Umgebungen bewegen, dass Richtung, Freigabe und Rückweg festgelegt sind. Drei Dinge, und alle drei müssen vorher feststehen.

10:50 Erfolgreich sind Sie, wenn der Weg mit Branch-Muster, Rollen und Freigabepunkt beschrieben ist, ein Konfliktfall durchgespielt wurde und die Rollback-Schritte benannt sind. Wer früh fertig ist, beschreibt, wie derselbe Weg über die n8n-API in eine Pipeline käme. Das ist die logische Fortsetzung — und der Punkt, an dem aus einem Ablauf eine Automatisierung wird.

11:12 Eine Stunde, fünf Schritte. Wählen Sie das Branch-Muster und begründen Sie die Wahl — es gibt vier, und für Kesselwerk sind mindestens zwei vertretbar. Legen Sie fest, wer auf welcher Instanz pushen und pullen darf. Schreiben Sie den Weg der Änderung Schritt für Schritt auf. Spielen Sie dann den Fall durch, dass zwei Personen denselben Workflow geändert haben — nicht besprechen, durchspielen. Und halten Sie die Rollback-Schritte fest, samt Auslöser.

11:39 Auslöser heißt: Woran erkennen Sie, dass zurückgedreht werden muss? Vier Fallen. Erstens: Gewählt wird ein Branch je Person, und niemand führt sie zusammen — dann haben Sie vier Wahrheiten. Zweitens: Der Konfliktfall wird beschrieben, aber nicht durchgespielt; die Beschreibung ist immer harmloser als die Wirklichkeit. Drittens: Credential-Platzhalter tauchen im Plan gar nicht auf — dabei sind sie der erste Punkt, an dem eine frisch gepullte Umgebung stolpert.

12:07 Und viertens: Der Rollback endet bei „Stand wiederherstellen", ohne zu sagen welchen. Im Ernstfall ist genau das die Frage, die niemand beantworten kann.