Frontend-Deployment

Jede Website besteht grob aus zwei Hälften. Die eine Hälfte ist das, was du im Browser siehst: Schaltflächen, Texte, Bilder, Menüs. Die andere Hälfte läuft unsichtbar auf fremden Rechnern und verwaltet zum Beispiel Nutzerkonten oder Bestellungen. Die sichtbare Hälfte nennt man Frontend. Frontend-Deployment ist der Vorgang, bei dem eine neue Fassung dieser sichtbaren Hälfte auf die Rechner gespielt wird, die sie an alle Besucher ausliefern. Vorher existiert die Änderung nur auf dem Laptop der Entwicklerin, danach bekommt sie jeder zu sehen.

Der Moment, in dem Änderungen echt werden

Solange Code nicht ausgerollt ist, hat er für Nutzer keinen Wert. Ein Team kann monatelang an einem neuen Bezahlvorgang arbeiten. Erst das Deployment entscheidet, ob dieser Vorgang tatsächlich benutzt wird. Deshalb gilt die Häufigkeit von Deployments in vielen Unternehmen als Kennzahl für Tempo.

Große Anbieter rollen ihr Frontend mehrmals täglich aus. Andere Firmen schaffen es nur alle paar Wochen. Der Unterschied ist selten die Qualität der Programmierer. Meist liegt es daran, wie stark der Vorgang automatisiert ist und wie leicht sich Fehler zurücknehmen lassen.

Gleichzeitig ist das Deployment der Punkt mit dem höchsten Risiko. Ein fehlerhaftes Frontend legt zwar keine Datenbank lahm, macht aber die gesamte Seite unbenutzbar. Eine kaputte Schaltfläche im Warenkorb kostet einen Onlineshop unmittelbar Umsatz. Deshalb bauen Teams viel Aufwand darin, den Vorgang langweilig und vorhersagbar zu machen.

Vom Quelltext zur ausgelieferten Seite

Am Anfang steht der Quelltext, also der von Menschen geschriebene Programmcode. Der ist für Browser meist nicht direkt geeignet. Ein Programm namens Build-Werkzeug übersetzt ihn deshalb in kompakte Dateien. Dabei werden Leerzeichen entfernt, Dateien zusammengefasst und Bilder verkleinert. Das Ergebnis ist ein Ordner mit fertigen Dateien, der sogenannte Build.

Bevor dieser Build veröffentlicht wird, laufen automatische Prüfungen. Tests kontrollieren, ob wichtige Abläufe noch funktionieren. Oft entsteht zusätzlich eine Vorschauversion unter einer geheimen Adresse. Dort schaut das Team die Änderung an, bevor sie auf die echte Domain geht.

Zur Auslieferung landen die Dateien auf einem Content Delivery Network, kurz CDN. Das ist ein Netz aus Servern in vielen Ländern, das Kopien der Dateien vorhält. Ein Besucher in Hamburg bekommt sie so aus einem nahen Rechenzentrum statt aus Kalifornien. Beliebt sind zwei Strategien für den Umschaltmoment: Beim Blue-Green-Deployment steht die neue Version komplett bereit, dann wird der Verkehr auf einmal umgeleitet. Beim Canary-Release erhalten zuerst nur wenige Prozent der Nutzer die neue Fassung.

Woran du ein Deployment als Nutzer merkst

Meist merkst du gar nichts, und genau das ist das Ziel. Auffällig wird es nur bei Pannen. Wenn eine App plötzlich seltsam aussieht oder eine Meldung erscheint wie « Neue Version verfügbar, bitte neu laden », steckt oft ein frisches Deployment dahinter. Auch Wartungsseiten mit dem Hinweis, man sei gleich zurück, gehören in diese Kategorie.

In Nachrichten aus der Tech-Branche taucht der Begriff auf, wenn Störungen erklärt werden. Firmen schreiben dann, ein fehlerhafter Rollout sei die Ursache gewesen und man habe zurückgerollt. Zurückrollen heißt: die vorherige Version wieder aktivieren. Bei einem sauber aufgesetzten Frontend dauert das oft weniger als eine Minute.

Ein häufiger Irrtum ist, Deployment sei dasselbe wie Programmieren oder wie Hosting. Programmieren erzeugt den Code, Hosting bezeichnet den dauerhaften Betrieb der Server. Deployment ist der Vorgang dazwischen, also die Übergabe. Anbieter wie Vercel, Netlify oder GitHub Pages haben daraus ein Geschäftsmodell gemacht: Man verbindet sein Code-Verzeichnis, und jede gespeicherte Änderung löst automatisch ein neues Deployment aus.