Deployment und Produktion

Deployment und Produktion

0:00 Letztes Modul, und es geht um den Schritt, der aus einem Projekt eine Anwendung macht: das Ausliefern. Wir sehen uns an, was beim Bauen passiert, warum sich der gebaute Stand anders verhält als der Entwicklungsserver, wie man Werte je Umgebung unterscheidet und was ein Webserver leisten muss. Am Ende steht eine Prüfliste mit sechs Punkten, die Sie vor jedem Deployment durchgehen können.

0:21 Das ist der Teil, den Kurse gern überspringen — und an dem im echten Leben die meisten Anwendungen scheitern.

Erstellung eines Produktions Builds

0:28 Fangen wir mit dem Bauen an. Ein Befehl, ein Ordner, fertig — so einfach ist es tatsächlich. Trotzdem lohnt sich ein Blick darauf, was dabei entsteht, denn das erklärt gleich mehrere Dinge, die später wichtig werden: warum die Dateinamen so merkwürdig aussehen, warum das für das Zwischenspeichern gut ist und warum Sie den gebauten Stand vor dem Ausliefern lokal ansehen sollten.

0:48 Der letzte Punkt ist der, den die meisten überspringen — und der ihnen später die unangenehmsten Überraschungen erspart hätte. Der Bau übersetzt Ihr Projekt in statische Dateien. Und der letzte Satz ist der entscheidende: Danach ist kein Node mehr nötig. Was herauskommt, ist HTML, CSS und JavaScript — Dateien, die jeder Webserver ausliefern kann, auch der billigste Webspace.

1:11 Das ist ein wichtiger Unterschied zu serverseitig gerenderten Anwendungen, die eine Laufzeitumgebung brauchen. Ihre Vue-Anwendung braucht nichts als einen Ort, an dem Dateien liegen dürfen. Das macht das Ausliefern erfreulich unkompliziert. Zwei Befehle. Der erste baut, der zweite liefert das Ergebnis lokal aus. Der zweite ist der, den viele nicht kennen, und ich möchte ihn Ihnen ans Herz legen: Er startet einen kleinen Server, der genau das ausliefert, was später auch auf dem Zielserver liegt.

1:41 Das ist die letzte Gelegenheit, Fehler zu finden, ohne dass jemand anders sie sieht. Und es ist ein anderer Port als beim Entwickeln — damit Sie nicht versehentlich den alten Tab ansehen. Fünf Zeilen, und die Prüfsumme in den Dateinamen ist der interessante Teil. Sie sieht nach einer Marotte aus und ist eine kluge Lösung für ein altes Problem: Wie sagt man dem Browser, er darf eine Datei ewig behalten, und wie sagt man ihm trotzdem Bescheid, wenn sie sich ändert?

2:08 Antwort: Man ändert den Namen. Bei gleichem Inhalt bleibt der Name gleich, und der Browser lädt gar nicht erst neu. Das ist der Grund, warum eine gut ausgelieferte Anwendung beim zweiten Besuch so schnell ist. Der zweite Punkt ist der, der im Ernstfall zählt: Fehler durch Verkleinerung oder Baumschütteln zeigen sich erst im Bau.

2:28 Der Entwicklungsserver liefert Ihren Code weitgehend unverändert aus. Der Bau dagegen benennt um, entfernt Ungenutztes und fasst zusammen — und dabei können Annahmen brechen, etwa wenn Code sich auf Funktionsnamen verlässt. Das passiert selten, aber wenn, dann gerne im ungünstigsten Moment. Zwei Minuten Prüfung ersparen Ihnen dann einen sehr unangenehmen Abend.

2:49 Der erste Punkt ist eine Klarstellung: Der Vorschau-Server ist kein Produktionsserver. Er hat keine Auffangregel, keine Kompression, keine Zwischenspeicherung — er dient nur der Prüfung. Der letzte Punkt ist eine Falle bei wiederholten Bauten: Alte Dateien im Zielordner überleben, wenn er nicht geleert wird. Das ist meist harmlos, kann aber zu der verwirrenden Situation führen, dass eine gelöschte Seite weiterhin ausgeliefert wird. Räumen Sie den Ordner vor jedem Bau.

Unterschiede zwischen Entwicklungs- und Produktionsmodus

3:18 Jetzt ein Kapitel, das erklärt, warum sich der gebaute Stand anders verhält. Vue liegt nämlich in zwei Fassungen vor, und die unterscheiden sich deutlicher, als man denkt. Das ist keine Kleinigkeit — es erklärt, warum Fehlermeldungen plötzlich unverständlich werden, warum die Entwicklerwerkzeuge nichts mehr anzeigen und warum Prüfungen, auf die Sie sich verlassen haben, nicht mehr stattfinden.

3:39 Wer diese Unterschiede kennt, deutet Fehlermeldungen aus dem Betrieb richtig, statt an der falschen Stelle zu suchen. Die Entwicklungsfassung ist gesprächig: Sie warnt, sie prüft, sie erklärt, und sie spricht mit den Entwicklerwerkzeugen. Die Produktionsfassung lässt das alles weg. Das Ergebnis ist deutlich kleiner und schneller — und deutlich stiller.

4:00 Das ist eine bewusste Abwägung: Hilfen beim Entwickeln kosten Größe und Zeit, und beides will man den Nutzern nicht aufbürden. Für Sie heißt das: Nehmen Sie Warnungen beim Entwickeln ernst, denn im Bau bekommen Sie sie nicht mehr. Fünf Zeilen, und die erste ist die praktisch wichtigste — deshalb steht sie auch in der Fußzeile. Die Eingabenprüfung aus Modul 7 entfällt im Bau vollständig.

4:23 Wer sie also als Schutz gegen fehlerhafte Daten eingeplant hat, hat im Betrieb keinen. Sie ist eine Entwicklungshilfe, nicht mehr. Die letzte Zeile ist der Grund, warum Fehlermeldungen im Bau so kryptisch wirken: Die Klartexte sind herausgerechnet, es bleibt eine Nummer. Die schlägt man in der Dokumentation nach. Sechs Zeilen mit den eingebauten Werten. Interessant ist die erste Bedingung: Der Bundler erkennt, dass der Zweig im Produktionsbau nie erreicht wird, und entfernt ihn samt Inhalt.

4:53 Sie können also getrost Prüfungen oder Ausgaben für die Entwicklung einbauen — sie landen nicht im ausgelieferten Code. Das ist Baumschütteln in seiner nützlichsten Form, und es funktioniert nur, weil diese Werte zur Bauzeit fest eingesetzt werden und nicht zur Laufzeit gelesen werden. Der erste Punkt beschreibt eine unangenehme Fehlerklasse: Ein Fehler, der nur im Bau auftritt.

5:14 Die Ursache liegt fast immer bei der Verkleinerung oder der Reihenfolge, in der Module geladen werden. Wenn Ihnen das passiert, ist der Vorschau-Server aus Kapitel eins Ihr bester Freund — dort können Sie es nachstellen. Der letzte Punkt ist die Mahnung, die aus diesem Kapitel folgt: Wer Warnungen beim Entwickeln ignoriert, verliert sie im Bau endgültig. Dann gibt es niemanden mehr, der Sie warnt.

Nutzung von Environment Variablen

5:38 Jetzt zu den Werten, die sich je Umgebung unterscheiden — typischerweise die Adresse Ihres Backends. Es gibt dafür einen einfachen Mechanismus mit Dateien, und es gibt eine Regel, die auf den ersten Blick wie eine Schikane wirkt und in Wahrheit eine Sicherheitsentscheidung ist. Über die möchte ich ausführlich sprechen, denn hier passieren die teuersten Fehler dieses Moduls — Fehler, die man nicht bemerkt, weil die Anwendung dabei einwandfrei funktioniert.

6:02 Der Mechanismus ist einfach: Werte in Dateien, und nur solche mit einem bestimmten Präfix erreichen Ihren Anwendungscode. Der letzte Satz ist der, um den es geht: Sie werden beim Bauen fest eingesetzt. Das heißt, sie stehen danach im ausgelieferten JavaScript — im Klartext, für jeden lesbar, der die Entwicklerwerkzeuge öffnet. Sie sind kein Geheimnis, sondern Teil des Bündels.

6:25 Wer das einmal verstanden hat, macht den häufigsten Fehler in diesem Bereich nicht mehr. Vier Dateien mit klarer Rangfolge. Die beiden mit dem Zusatz für lokale Werte gehören nicht ins Repository — dort stehen die Dinge, die nur auf Ihrem Rechner gelten. Die Fußzeile nennt die Regel: Die modusabhängige Datei hat Vorrang. Damit können Sie allgemeine Werte in die Grunddatei schreiben und nur die Abweichungen je Umgebung ergänzen.

6:51 Das ist dasselbe Muster wie bei Konfigurationsdateien überall — Grundlage plus Überschreibung. Sechs Zeilen, und der Kontrast ist der Inhalt der Folie: Der erste Wert trägt das Präfix und erreicht Ihren Code. Der zweite nicht — und der bleibt beim Bauprozess. Er ist also nicht etwa geheim, aber er landet zumindest nicht im Bündel.

7:11 Das ist genau die Unterscheidung, die das Präfix leistet: Es macht die Veröffentlichung zu einer bewussten Entscheidung, statt zu einem Versehen. Und im Code lesen Sie den Wert über dasselbe Objekt wie die eingebauten Werte aus Kapitel zwei. Der zweite Punkt ist die Begründung: Ohne Präfix wäre jede Variable versehentlich im Bündel gelandet.

7:31 Und in einer typischen Umgebungsdatei stehen eben nicht nur harmlose Adressen, sondern auch Datenbankpasswörter und Schlüssel für Dienste. Ein Werkzeug, das die alle ins Frontend kopiert, wäre eine Katastrophe mit Ansage. Der letzte Punkt ist die Konsequenz für Ihre Architektur: Echte Geheimnisse gehören auf den Server. Wenn Ihr Frontend einen Schlüssel braucht, brauchen Sie in Wahrheit einen Vermittler dazwischen.

7:55 Der erste Punkt ist der teuerste Fehler dieses Moduls, und er passiert regelmäßig: ein Schlüssel mit Präfix. Er steht dann im ausgelieferten JavaScript, und Suchmaschinen für Quelltexte finden so etwas zuverlässig. Der zweite Punkt kostet nur Zeit, aber die regelmäßig: Änderungen an Umgebungsdateien wirken erst nach einem Neustart des Entwicklungsservers.

8:15 Wer das nicht weiß, sucht den Fehler im Code. Und der dritte: Alle Werte sind Zeichenketten, auch wenn dort das Wort wahr steht.

Deployment auf Webservern

8:23 Jetzt der Schritt nach draußen. Die gute Nachricht steht schon in Kapitel eins: Es sind statische Dateien, jeder Webserver kann das. Die weniger gute ist, dass zwei Einstellungen dazugehören, die niemand automatisch für Sie macht — eine Regel für die Adressen und eine sinnvolle Zwischenspeicherung. Beide sehen wir uns an, und beide sind in wenigen Zeilen erledigt.

8:44 Gemeinsam ist ihnen, dass ihr Fehlen nicht sofort auffällt — sondern erst dann, wenn schon Nutzer auf der Seite sind. Der erste Teil ist die Entlastung: kein Node, keine Laufzeit, kein Prozess, der laufen muss. Sie kopieren Dateien. Der zweite Teil nennt die beiden nötigen Einstellungen. Die Auffangregel kommt im nächsten Kapitel ausführlich, die Zwischenspeicherung gleich.

9:07 Beide haben gemeinsam, dass sie beim ersten Deployment fehlen und der Fehler nicht sofort auffällt — bei der einen erst beim Neuladen einer Unterseite, bei der anderen erst beim zweiten Deployment. Fünf Schritte, und Schritt fünf ist der, der in der Fußzeile steht und den man zuverlässig vergisst: den direkten Aufruf einer Unterseite prüfen.

9:27 Nicht hinklicken — die Adresse eintippen und die Eingabetaste drücken. Oder noch besser: eine Unterseite öffnen und dann neu laden. Das ist der Test, der die Auffangregel prüft, und er dauert zehn Sekunden. Ohne ihn merken Sie den Fehler erst, wenn jemand Ihnen schreibt, dass ein geteilter Link nicht funktioniert. Drei Zeilen, und die zweite ist die entscheidende: Die Hauptdatei darf nicht zwischengespeichert werden. Alles andere darf und soll — es trägt ja die Prüfsumme im Namen.

9:56 Die Fußzeile beschreibt, was sonst passiert, und das ist ein Fehlerbild, das man einmal erlebt und nie vergisst: Nach einem Deployment sehen manche Nutzer eine weiße Seite, andere nicht, und ein erzwungenes Neuladen behebt es. Die Ursache ist immer dieselbe. Hier die Erklärung Schritt für Schritt. Die Hauptdatei enthält die Verweise auf die Bündeldateien — und nach einem Deployment heißen die anders, weil sich ihr Inhalt geändert hat.

10:21 Wenn der Browser nun eine alte Hauptdatei aus seinem Zwischenspeicher nimmt, verweist die auf Dateien, die es nicht mehr gibt. Das Ergebnis ist der letzte Punkt: eine weiße Seite ohne Serverfehler. In den Entwicklerwerkzeugen sieht man dann Fehler beim Laden der Bündel — aber der normale Nutzer sieht nur Weiß. Der erste Punkt ist der Klassiker beim ersten Deployment: Man lädt den Ordner hoch statt seines Inhalts. Dann liegt alles eine Ebene zu tief, und sämtliche Pfade stimmen nicht.

10:49 Der dritte Punkt ist eine Anforderung, die man heute kaum noch erwähnen muss und die trotzdem gelegentlich fehlt: Ohne verschlüsselte Verbindung funktionieren viele Browser-Schnittstellen gar nicht erst — die Zwischenablage, Standortdienste, Benachrichtigungen. Der letzte Punkt ist ein Rat zur Vorsicht beim Ersetzen.

Handling von Deep Links im Server Setup

11:07 Jetzt das Kapitel, auf das ich seit Modul 8 verweise. Ein Deep Link ist der direkte Aufruf einer Unterseite — und das ist der Normalfall, sobald jemand ein Lesezeichen setzt oder einen Link weitergibt. Ohne eine Regel auf dem Server scheitert genau das, und zwar auf eine Art, die beim Entwickeln nie auftritt. Wir sehen uns die Regel für die beiden verbreitetsten Server an.

11:28 Der Ablauf in einem Satz: Der Browser fragt den Pfad beim Server an, dort liegt keine Datei, also muss der Server stattdessen die Hauptdatei ausliefern. Erst danach kann der Router im Browser die Adresse auflösen. Wichtig ist die Reihenfolge dieser Kette — der Router kann nichts tun, solange die Anwendung nicht geladen ist.

11:47 Und die Anwendung wird nicht geladen, solange der Server auf eine unbekannte Adresse mit einem Fehler antwortet. Drei Zeilen, und die Reihenfolge darin ist der ganze Trick. Zuerst wird geprüft, ob es die Datei wirklich gibt, dann ob es ein Verzeichnis ist, und erst als Letztes greift der Rückfall auf die Hauptdatei. Diese Reihenfolge ist wichtig: Ohne sie würden auch Ihre Bündeldateien und Bilder durch die Regel laufen und HTML zurückliefern — mit dem Ergebnis, dass gar nichts mehr funktioniert.

12:15 Der Fehler ist selten und dann sehr verwirrend. Dieselbe Logik in der Apache-Schreibweise. Die beiden Bedingungen in der Mitte sind das Gegenstück zur Prüfung von eben: keine existierende Datei, kein existierendes Verzeichnis. Nur dann greift die Umschreibung. Diese Datei legen Sie in das Wurzelverzeichnis Ihrer Anwendung, und viele Webhoster erlauben das auch bei einfachen Paketen.

12:37 Falls Ihr Anbieter die Umschreibung nicht erlaubt, bleibt Ihnen die Hash-Variante aus Modul 8 — mit den bekannten Nachteilen. Das ist die Nebenwirkung, an die man nicht denkt. Nach der Regel meldet der Server nie mehr einen Nicht-gefunden-Fehler — jede Adresse liefert Ihre Anwendung aus. Der zweite Punkt macht es konkret: Auch ein Tippfehler in der Adresse führt zu Ihrer Anwendung. Und wenn die dafür keine Route hat, sieht der Besucher eine leere Seite.

13:04 Der letzte Punkt nennt die Lösung, die Sie in Modul 8 schon gebaut haben: die Auffangroute, und zwar als letzte in der Liste. Der Hinweis unten ist der Kern dieser Aufgabe, und ich betone ihn: Der Nachweis gelingt nur durch Neuladen. Wenn Sie in der Anwendung auf einen Link klicken, navigiert der Router — der Server wird gar nicht gefragt, und die Regel wird nie geprüft.

13:26 Sie müssen die Seite wirklich neu laden oder die Adresse in einem neuen Tab öffnen. Der zweite Teil des Kriteriums ist die Auffangroute: Ein erfundener Pfad soll Ihre eigene Fehlerseite zeigen, nicht eine leere. Der erste Punkt ist die Falle aus Folie 27, und ich wiederhole sie, weil sie schwer zu diagnostizieren ist: Die Regel darf statische Dateien nicht überdecken.

13:48 Der zweite Punkt ist die eigentliche Tücke dieses ganzen Kapitels: Im Entwicklungsserver funktioniert alles. Vite hat die Regel nämlich eingebaut. Sie können den Fehler lokal gar nicht erzeugen — er entsteht erst dort, wo Sie ihn am wenigsten sehen wollen. Deshalb der Nachweis nach dem Deployment.

Anpassung der Build Konfiguration

14:06 Ein kurzes Kapitel über die Konfigurationsdatei. Sie ist bei Vite erfreulich klein, und im Alltag brauchen Sie vier Einstellungen davon. Ich zeige Ihnen diese vier, damit Sie sie erkennen, wenn Sie ihnen begegnen — und damit Sie wissen, wo Sie nachsehen müssen, wenn eine Anwendung sich unerwartet verhält, etwa weil sie in einem Unterverzeichnis liegt.

14:26 Genau dieser Fall ist der häufigste Anlass, die Datei überhaupt zu öffnen. Vier Angaben für den Alltag: der Basispfad, Aliasnamen für Importe, der Zielordner und ein Proxy für die Entwicklung. Das ist wirklich alles, was die meisten Projekte brauchen. Der Rest der Konfigurationsmöglichkeiten ist für Sonderfälle — eigene Plugins, besondere Bündelstrategien, Bibliotheksbau.

14:48 Wenn Ihre Konfigurationsdatei also anfängt, auf mehr als eine Bildschirmseite zu wachsen, lohnt sich die Frage, ob wirklich alles davon nötig ist. Zehn Zeilen mit den vier Einstellungen. Der Basispfad ist für den Betrieb in einem Unterverzeichnis — davon gleich mehr. Der Aliasname macht aus langen relativen Pfaden kurze, und den werden Sie im Projekt überall sehen.

15:10 Der Proxy in den letzten Zeilen ist der praktische Trick beim Entwickeln: Anfragen an das Backend laufen über den Entwicklungsserver, damit der Browser sie als gleichherkünftig ansieht. Die Fußzeile sagt, was viele überrascht — in Produktion greift das nicht. Fünf Zeilen, und die Fußzeile enthält eine Abhängigkeit, die Sie sich merken sollten: Der Basispfad und der Router müssen zusammenpassen.

15:33 Wenn Ihre Anwendung in einem Unterverzeichnis liegt, muss beides davon wissen — sonst erzeugt der Router Adressen, die auf dem Server nirgends hinführen. Die letzte Zeile ist ein zweischneidiges Werkzeug: Quellkarten helfen bei der Fehlersuche im Bau und machen zugleich Ihren Originalcode für jeden lesbar. Der erste Punkt ist eine winzige Ursache mit großer Wirkung: ein fehlender Schrägstrich am Ende des Basispfads. Die Pfade sind dann alle um ein Zeichen verschoben, und nichts lädt.

16:02 Der dritte Punkt ist eine ehrliche Warnung zum Proxy: Er ist bequem und täuscht zugleich darüber hinweg, dass die Herkunftsfrage auf dem Zielserver ungelöst ist. Wer sich darauf verlässt, hat beim Deployment eine unangenehme Überraschung — nämlich blockierte Anfragen.

Best Practices für produktive Vue-Anwendungen

16:18 Zum Abschluss des Seminars die Frage, was zwischen läuft und trägt liegt. Ich habe dafür eine Prüfliste mit sechs Punkten mitgebracht, die sich in einer Viertelstunde abarbeiten lässt. Dazu kommen zwei Themen, die man früh angehen sollte, weil sie später teuer werden: das zentrale Auffangen von Fehlern und die Größe des ausgelieferten Bündels.

16:37 Beides sind Dinge, die am Anfang fast nichts kosten und nachträglich zu eigenen Projekten werden. Der erste Satz ist die Botschaft: Produktionsreife heißt nicht, dass der Bau durchläuft. Ein grüner Bau bedeutet nur, dass der Code übersetzbar war. Ob die Anwendung mit Fehlern umgeht, ob sie in vertretbarer Zeit lädt und ob Sie mitbekommen, wenn beim Nutzer etwas schiefgeht — das sind eigene Fragen.

17:00 Die drei genannten Punkte decken den größten Teil davon ab, und keiner davon kostet mehr als eine halbe Stunde. Sechs Punkte, und die rechte Spalte sagt jeweils, wie Sie prüfen. Die ersten beiden gehören zusammen und sind die aus Kapitel fünf. Der dritte kommt gleich. Der vierte ist der, den man am ehesten schleifen lässt — sehen Sie sich die Bündelgröße wenigstens einmal an, bevor Sie ausliefern.

17:25 Der fünfte ist die Sicherheitsfrage aus Kapitel drei. Und der sechste ist die Zwischenspeicherungsregel. Die Fußzeile ist ernst gemeint: eine Viertelstunde, mehr ist es nicht. Drei Zeilen für etwas, das den Unterschied zwischen Ahnungslosigkeit und Übersicht macht. Dieser Handler fängt Fehler aus allen Komponenten Ihrer Anwendung.

17:45 Was Sie damit tun, ist Ihre Entscheidung — im einfachsten Fall schicken Sie sie an einen Dienst, der sie sammelt. Ohne so etwas erfahren Sie von Fehlern nur, wenn jemand sich beschwert, und die meisten Nutzer beschweren sich nicht. Sie gehen einfach. Die Fußzeile enthält die bekannte Regel: vor dem Einhängen. Der zweite und dritte Punkt beschreiben das Werkzeug: Der Router kann Ansichten über dynamische Importe nachladen, und zwar erst dann, wenn die Route tatsächlich aufgerufen wird.

18:13 Das ist eine Änderung von wenigen Zeichen je Route und kann die Größe des ersten Ladevorgangs erheblich senken. Der letzte Punkt sagt, wo es sich am meisten lohnt: bei selten besuchten Bereichen. Ein Verwaltungsbereich, den fünf Prozent der Nutzer öffnen, muss nicht bei jedem Seitenaufruf mitgeladen werden. Die Abschlussaufgabe des Seminars, und der Hinweis unten ist der Kern: Wer nur den Bau prüft, hat den halben Weg.

18:38 Der Nachweis läuft über den ausgelieferten Stand — also mindestens über den Vorschau-Server, besser über den echten Zielserver. Gehen Sie die sechs Punkte der Prüfliste durch und schließen Sie die Lücken. Sie werden vermutlich zwei oder drei finden, und das ist völlig normal — genau dafür gibt es die Liste. Der zweite Punkt ist eine Beobachtung aus der Praxis: Die Bündelgröße wächst unbemerkt.

19:01 Jede Abhängigkeit bringt ihre eigenen mit, und niemand sieht hin, bis jemand sich über die Ladezeit beschwert. Der letzte Punkt ist der, mit dem ich dieses Seminar gern schließe: Barrierefreiheit und Ladeverhalten lassen sich später nur teuer nachrüsten. Beides ist am Anfang fast umsonst zu haben und später ein Projekt für sich. Denken Sie früh daran.

Vue in der Praxis

19:22 Damit sind wir am Ende. Der Bau erzeugt statische Dateien, die jeder Webserver ausliefern kann. Auffangregel und Auffangroute gehören zusammen. Und was mit dem Präfix beginnt, ist öffentlich — Geheimnisse bleiben auf dem Server. Damit ist der Weg vollständig: von der ersten Komponente in Modul 1 über Templates, Reaktivität, Kommunikation, Routing, Daten und Zustand bis hierher.

19:45 Sie haben jetzt alles beisammen, um eine Vue-Anwendung nicht nur zu bauen, sondern auch zu betreiben.