Deploy: Wie Code zu echten Menschen kommt

Dein Projekt läuft. Du hast es deinen Freunden auf deinem Laptop gezeigt, und es lief. Also legst du es auf einen Server, verschickst den Link — und es bricht sofort. Derselbe Code, dieselben Dateien, alles gleich. Geändert hat sich nur, wo es läuft. Dieser Moment hat einen Namen, und der Name ist ein Witz, den Leute erzählen, weil er allen passiert: „Bei mir auf dem Rechner lief es aber.“

Es brach, weil dein Laptop nie nur deinen Code ausgeführt hat. Er hat auch hundert Dinge geliefert, von denen dein Code still abhängt: auf welchem Port er lauschen soll, wo die Datenbank liegt, welche API-Schlüssel zu benutzen sind, welche Version der Sprache installiert ist, welche Dateien zufällig in diesem Ordner liegen. Nichts davon steht in deinem Code, also ist nichts davon mit deinem Code mitgereist. Die Orte, an denen dein Code läuft, heißen Umgebungen. Üblich sind drei: dein Laptop, auf dem du baust und auf dem kaputtgehen in Ordnung ist; Staging, eine Kopie des echten Aufbaus, auf der das Team prüft, bevor Nutzer etwas sehen; und Produktion, das Echte mit echten Menschen und echtem Geld. Dasselbe Programm läuft in allen drei, und die Werte sind in jeder anders.

env:         laptop     staging    production
-----------  ---------  ---------  -----------
PORT         3000       8080       80
API_KEY      test       test       live
LOG_LEVEL    debug      info       warn

Bevor Code auf einem Server laufen kann, muss er oft erst in etwas verwandelt werden, das der Server ausführen kann: Das ist der Build. TypeScript zu JavaScript kompilieren, viele Dateien zu einer bündeln, Bilder verkleinern, einen fertigen Ordner erzeugen, der gestartet werden kann. Der Unterschied ist wichtig, weil das zwei verschiedene Schritte mit zwei verschiedenen Arten des Scheiterns sind. Ein Build-Fehler passiert auf deiner Maschine, vor jedem Deploy, und ist billig: Noch ist nichts bei Nutzern angekommen. Ein Laufzeitfehler passiert auf dem Server, während Nutzer zusehen. Du willst, dass möglichst viele Fehler Build-Fehler sind.

src/cart.ts       ---> dist/app.js
package.json      ---> node_modules/

ts ---> js

$ npm start
PORT=80 listening

Die ehrliche Version von „es läuft auf meiner Maschine“ ist also eine Checkliste, und sie ist kurz. Ist die Konfiguration hier anders — Port, Datenbank, Schlüssel? Fehlt eine Abhängigkeit oder hat sie eine andere Version? Ist die Datei, die der Code erwartet, auf dieser Maschine wirklich da, mit derselben Groß- und Kleinschreibung? Darf diese Maschine Netzwerk, Ordner und Port überhaupt benutzen? Und — der Punkt, den alle vergessen — funktioniert es auch jetzt noch, zu dieser Stunde, unter dieser Last? Keine dieser Fragen handelt davon, wie klug dein Code ist. Sie handeln von der Welt, in der er gelandet ist.

Jeder Deploy ist auch eine kleine Wette. Entscheide also vor dem Deploy, wie du zurückkommst. Dieser Plan hat einen Namen: ein Rollback. Er bedeutet, zur vorherigen Version zurückzugehen, von der man weiß, dass sie lief — meist mit einem Befehl, und das sollte in Sekunden gehen, nicht in Stunden. Der Sinn eines Rollbacks ist nicht, etwas zu reparieren: Er ist, den Schaden zu stoppen, während du herausfindest, was schiefging. Beachte, was er voraussetzt. Die vorherige Version muss noch existieren und noch laufen. Die Daten müssen die Reise rückwärts überstehen, und das ist der schwierige Teil: Hat die neue Version schon eine neue Art von Datensatz geschrieben, muss die alte Version ihn tolerieren. Und du musst wissen, dass etwas kaputt ist — also direkt nach dem Deploy hinschauen statt anzunehmen.