Deployment: wie du deine Seite online bringst, ohne dass sie crasht

Was Deployment ganz einfach bedeutet

Du hast eine Seite gebaut. Auf deinem Rechner läuft sie perfekt: schön, schnell, alles klickt sich gut. Ein Problem nur. Außer dir sieht sie keine einzige Menschenseele. Damit die Welt deine Seite sieht, musst du das Projekt ins Internet bringen. Genau dieser Umzug heißt Deployment Deployment (deploy) - das Veröffentlichen eines Projekts auf einem Server im Internet, damit echte Menschen es nutzen können und nicht nur du auf deinem Rechner. .

Vergleich es mit dem Umzug in eine neue Wohnung. Methode eins: du räumst erst die kompletten Möbel aus der alten Wohnung raus und schleppst dann einen halben Tag lang die neuen rein - und die ganze Zeit hast du nicht mal einen Platz zum Hinsetzen. Methode zwei: du fährst die neuen Möbel rein, stellst sie auf, checkst, dass alles gerade steht, und erst dann räumst du die alte weg. Keine Sekunde ohne Sofa.

Gutes Deployment ist immer Methode zwei. Der User soll gar nicht merken, dass du überhaupt was angefasst hast. Die Seite lief - und läuft weiter, nur ist sie jetzt besser.

Warum ein Vibecoder das Veröffentlichen verstehen sollte

Du bist Vibecoder. Den Code schreibt der Agent für dich. Aber den „veröffentlichen“-Knopf drückst am Ende du. Und für eine abgestürzte Seite haftest auch du. Wenn du verstehst, wie Deployment funktioniert, dann:

• rollst du Updates so aus, dass Besucher nichts mitbekommen;
• zeigst du deine Passwörter und Keys nicht dem ganzen Internet (der häufigste und teuerste Anfängerfehler);
• kannst du in Sekunden zurückrollen, statt dem Agenten panisch „mach es wieder wie vorher!!!“ zu tippen;
• verstehst du, was sich hinter den gruseligen Wörtern rollback, health check, staging verbirgt - und kannst den Agenten ganz entspannt bitten, das alles einzurichten.

Der Unterschied zwischen „ich hab die Seite online gestellt und sie liegt am Boden“ und „ich hab die Seite online gestellt und allen geht es gut“ läuft fast immer auf vier Dinge hinaus: wie du ausrollst, wo du Secrets speicherst, wie du prüfst, dass es läuft und ob es einen Rollback-Plan gibt. Gehen wir der Reihe nach durch.

Vier Säulen für entspanntes Deployment

1. Wie du Updates ausrollst, ohne dass etwas crasht

Eine winzige Seite auf einem einzigen Server? Dann ist alles simpel: die neue Version ersetzt die alte, fertig. Aber sobald das Projekt wächst, gibt es schlaue Methoden, so zu updaten, dass die Seite keine Sekunde liegt. Hier die drei wichtigsten, vom Einfachen zum Zuverlässigen.

• Rolling Rolling deployment - Update der Reihe nach: die Server schalten einer nach dem anderen auf die neue Version um, nicht alle auf einmal. Die Seite läuft die ganze Zeit. (der Reihe nach). Du hast mehrere Kopien der Seite. Du updatest sie nicht alle auf einmal, sondern eine nach der anderen: während eine auf die neue Version umzieht, halten die anderen die Besucher. Niemand bleibt ohne Seite.
• Blue-green Blue-green deployment - zwei identische Umgebungen: auf der einen läuft die alte Version, daneben wird die neue vorbereitet. Im richtigen Moment wird der Traffic blitzschnell auf die neue umgeschaltet. (zwei Umgebungen). Zwei identische Kopien: die „blaue“ läuft gerade live, die „grüne“ steht startklar mit der neuen Version. Grüne gecheckt - Hebel umgelegt, und der gesamte Traffic ist drüben. Was stimmt nicht? Hebel zurück - sofortiger Rollback.
• Canary Canary deployment - die neue Version wird zuerst nur einem kleinen Teil der Besucher gezeigt (zum Beispiel 5 %). Wenn bei denen alles gut läuft, wird sie schrittweise für alle freigeschaltet. (Kanarienvogel). Die neue Version sehen zuerst nur 5 % der Besucher. Denen geht es gut - du schaltest die Hälfte frei, dann alle. Der Name kommt von den Kanarienvögeln im Bergbau: wenn was nicht stimmt, merkst du es an einer kleinen Gruppe, nicht gleich an allen.

2. Wo du Secrets speicherst: Umgebungsvariablen, nicht Code

Das ist die wichtigste Regel der Lektion. Ein Projekt hat Secrets Secrets - Passwörter, Datenbank-Keys, Tokens von Bezahldiensten und andere Daten, mit denen man in dein Projekt reinkommt. Die darfst du niemandem zeigen. : das Passwort für die Datenbank, den Key für den Bezahldienst, den Bot-Token. Wenn die direkt im Code stehen, dann gehen - sobald der Code ins Internet wandert (und das tut er - zum Beispiel auf GitHub) - die Secrets mit ihm mit und werden für jeden sichtbar.

Richtig ist, sie in Umgebungsvariablen Umgebungsvariablen (environment variables) - Einstellungen, die getrennt vom Code direkt auf dem Server festgelegt werden. Der Code holt sie sich von dort, aber im Code selbst stehen sie nicht. zu speichern. Das ist wie der Wohnungsschluessel: der ist nicht mit Farbe auf die Tür gemalt, sondern liegt in deiner Tasche. Der Code weiß: „der Schlüssel ist irgendwo da, ich hol ihn im richtigen Moment“ - aber der Schlüssel selbst ist nicht im Code.

3. Health-Check: die Service-Seite „lebst du noch?“

Ein Health-Check Health-Check - eine simple Adresse auf der Seite (zum Beispiel /health), die „alles ok“ antwortet. Damit prüft der Server automatisch, ob das Projekt läuft. ist eine winzige Service-Seite, zum Beispiel unter der Adresse /health, die einfach „bei mir ist alles in Ordnung“ antwortet. Du selbst gehst da nie drauf. Sie ist für Maschinen, nicht für Menschen.

Und wozu das Ganze? Der Server ruft diese Seite alle halbe Minute auf und fragt: „lebst du?“. Antwortet sie „ja“ - super, weiter geht es. Schweigt sie oder meckert - merkt der Server, dass das Projekt hängt, und kann es selbst neu starten oder keine Leute mehr drauflassen. Das ist wie der Puls beim Patienten: der Monitor piept gleichmäßig - alle sind ruhig; das Signal fällt weg - die Krankenschwester kommt angerannt.

4. Rollback-Plan: der „mach es wieder wie vorher“-Knopf

Selbst Profis passiert es: Update ausgerollt, und es hat die Seite zerschossen. Der Unterschied zwischen Profi und Anfänger ist genau einer: der Profi hat einen „zurück“-Knopf. Das ist der Rollback Rollback - schnelle Rückkehr zur vorherigen funktionierenden Version des Projekts, falls die neue kaputt ist. .

Auf ordentlichen Plattformen ist ein Rollback buchstäblich ein Knopf oder ein Befehl: „vorherige Version zurückholen“. Der alte funktionierende Build liegt immer gespeichert bereit. Deshalb ist die richtige Denkweise beim Deployment nicht „Hauptsache, es läuft an“, sondern „falls es nicht anläuft - wie hole ich in 10 Sekunden alles zurück?“.

Gutes Deployment gegen schlechtes: der Vergleich

Staging Staging - eine Testkopie der Seite, genau wie live, aber für User gesperrt. Darauf werden Updates vor dem Veröffentlichen geprüft. in dieser Liste ist ein eigener Held. Das ist eine Kopie deiner Seite, auf der du erst alles prüfst und erst dann auf live ausrollst. Billig, langweilig und rettet jede Menge Nerven.

Beispiel aus dem Leben: wie ein Bot-Token leakt

Du hast mit dem Agenten eine Visitenkarten-Seite mit Anmeldeformular gebaut. Das Formular schickt Anfragen per Bot zu dir in Telegram - dafür braucht es einen Bot-Token. Der Agent hat den Token schnell direkt in den Code geschrieben, du hast dich gefreut, dass alles läuft, und das Projekt auf ein öffentliches GitHub gepusht. Bis zum Abend verschickt dein Bot Spam an wildfremde Leute, und die Seite verliert bei jedem Update für ein paar Minuten das Formular, weil du direkt auf die Live-Version ausrollst. Lustig, oder?

Was schiefgelaufen ist:

1. Der Token lebte im Code und ist in das öffentliche Repo geleakt - Bots haben ihn in Minuten aufgegriffen.
2. Es gab keinen Health-Check und kein Staging - Updates wurden direkt an der Live-Seite geprüft.
3. Es gab keinen Rollback-Plan - als das Formular kaputtging, war nichts da, um die funktionierende Version zurückzuholen.

Und so hätte es ein Vibecoder gemacht, der es verstanden hat. Er hätte dem Agenten einfach sauber die Aufgabe gestellt.

Hilf mir, mein Projekt für die Veröffentlichung im Internet vorzubereiten. Mach es Schritt für Schritt:

Finde im Code alle Secrets - Tokens, Passwörter, Keys. Lagere sie in Umgebungsvariablen aus und erstelle eine env-Beispieldatei mit leeren Werten. Stell sicher, dass die echten Secrets NICHT ins Repository gelangen, und füge sie zur gitignore hinzu.
Füge einen einfachen Health-Check unter der Adresse slash health hinzu, der mit dem Status ok antwortet.
Erklär mir mit einfachen Worten, wie ich auf meiner Plattform (ich nutze Vercel) auf die vorherige Version zurückrolle, falls die neue kaputtgeht.
Bevor du sagst, dass alles fertig ist, geh eine kurze Bereitschafts-Checkliste für die Veröffentlichung durch und zeig sie mir mit Häkchen.
Zeig jeden Schritt einzeln und warte auf mein ok, bevor du weitermachst.

Bereitschafts-Checkliste für die Veröffentlichung: 60 Sekunden vor dem Knopf

Bevor du auf „veröffentlichen“ drückst, überflieg das. Das ist eine vereinfachte Version der professionellen Checkliste aus dem Skill deployment-patterns:

1. Tests bestanden? Falls der Agent Tests gemacht hat - sind die grün?
2. Keine Secrets im Code? Kein einziges Passwort, kein Key, kein Token direkt in den Dateien.
3. Health-Check antwortet? Geh auf /health - steht da „ok“?
4. Weißt du, wie du zurückrollst? Nicht „kriege ich schon raus, falls was ist“, sondern jetzt schon den Befehl oder Knopf kennen.
5. Auf Staging geprüft? Hat das Update erst auf der Testkopie gelebt, und nicht gleich auf live?
6. Zeitpunkt mit Köpfchen gewählt? Nicht Freitagabend und nicht fünf Minuten vor einem wichtigen Termin.

Pixel-Merkzettel

Häufige Anfängerfehler beim Deployment

• Secrets in den Code schreiben. Die leaken zusammen mit dem Projekt. Nur Umgebungsvariablen, ohne Ausnahme.
• Direkt auf live ausrollen. Erst Staging, dann die Welt. Sonst testest du an echten Menschen.
• Keinen Rollback-Plan haben. „Falls es kaputtgeht - kriege ich schon hin“ ist kein Plan. Ein Plan ist der „zurück“-Knopf, den du vorher kennst.
• Den Health-Check ignorieren. Ohne ihn erfährst du vom Absturz als Letzter - von wütenden Usern.
• Freitagabend deployen. Alte Ingenieursweisheit: es geht genau dann kaputt, wenn niemand mehr zum Reparieren da ist.
• Die Datenbank in Eile „für immer“ ändern. Daten mit der neuen Version gelöscht - der Code-Rollback holt sie nicht zurück.