Bereitstellung unserer App

Nach der Entwicklung

In diesem Abschnitt des Projektlebenszyklus gibt es potenziell eine große Bandbreite an Problemen, die zu lösen sind. Daher ist es wichtig, eine Toolchain zu erstellen, die diese Probleme auf eine Weise löst, die so wenig manuelle Eingriffe wie möglich erfordert.

Hier sind einige Punkte, die für dieses spezielle Projekt zu berücksichtigen sind:

• Erstellung eines Produktions-Builds: Sicherstellung, dass Dateien minimiert, in Blöcke aufgeteilt sind, Tree-Shaking angewendet wurde und die Versionen "Cache-busting" haben.
• Tests durchführen: Diese können von "Ist der Code richtig formatiert?" bis hin zu "Funktioniert das, was ich erwarte?" reichen, und sicherstellen, dass fehlschlagende Tests die Bereitstellung verhindern.
• Aktualisierten Code tatsächlich auf eine Live-URL bereitstellen: Oder möglicherweise auf eine Staging-URL, damit er zuerst überprüft werden kann.

Diese Aufgaben untergliedern sich auch in weitere Aufgaben; beachten Sie, dass die meisten Webentwicklungsteams ihre eigenen Begriffe und Prozesse für mindestens einen Teil der Nachentwicklungsphase haben.

Für dieses Projekt werden wir das kostenlose statische Hosting-Angebot von GitHub Pages nutzen, um unser Projekt zu hosten. Es bietet nicht nur unsere Website im Internet an, sondern gibt uns auch eine URL zu unserer Website. Es ist großartig – viele MDN-Beispielwebsites sind auf GitHub Pages gehostet.

Die Bereitstellung auf einem Host erfolgt meist am Ende des Projektlebenszyklus, aber mit Diensten wie GitHub Pages, die die Kosten für Bereitstellungen senken (sowohl in finanzieller Hinsicht als auch in Bezug auf die Zeit, die tatsächlich für die Bereitstellung erforderlich ist), ist es möglich, während der Entwicklung zu deployen, um entweder Fortschritte zu teilen oder eine Vorversion aus einem anderen Zweck heraus zu veröffentlichen.

GitHub bietet einen reibungslosen Workflow, um neuen Code in eine Live-Website zu verwandeln:

• Sie laden Ihren Code auf GitHub hoch.
• Sie definieren eine GitHub Action, die ausgelöst wird, wenn ein neuer Push zum Hauptzweig erfolgt, der den Code erstellt und an einem bestimmten Ort platziert.
• GitHub Pages stellt den Code dann unter einer bestimmten URL bereit.

Genau solche verbundenen Dienste ermutigen wir Sie zu suchen, wenn Sie Ihre eigene Build-Toolchain entscheiden. Wir können unseren Code committen und auf GitHub pushen, und der aktualisierte Code wird automatisch den gesamten Build-Prozess auslösen. Wenn alles gut geht, bekommen wir eine automatische Live-Bereitstellung. Die einzige Aktion, die wir ausführen müssen, ist dieser initiale "Push".

Allerdings müssen wir diese Schritte einrichten, und das werden wir uns jetzt ansehen.

Der Build-Prozess

Da wir Vite für die Entwicklung verwenden, ist die Hinzufügung der Build-Option sehr einfach. Wie wir bereits gesehen haben, haben wir bereits ein benutzerdefiniertes Skript npm run build, das Vite alles bereitstellen lässt, was für den Produktionsbetrieb bereit ist, anstatt es nur für Entwicklungs- und Testzwecke auszuführen. Dies beinhaltet die Minimierung und das Tree-Shaking des Codes sowie das Cache-Busting der Dateinamen.

Es ist eine gute Praxis, immer ein build-Skript in Ihrem Projekt zu definieren, damit wir uns auf npm run build verlassen können, um immer den vollständigen Build-Schritt auszuführen, ohne sich die spezifischen Build-Befehlsargumente für jedes Projekt merken zu müssen.

Der neu erstellte Produktionscode wird in einem neuen Verzeichnis namens dist gespeichert, das alle Dateien enthält, die erforderlich sind, um die Website auszuführen und die Sie auf einen Server hochladen können.

Allerdings ist das manuelle Ausführen dieses Schrittes nicht unser endgültiges Ziel — wir möchten, dass der Build automatisch erfolgt und das Ergebnis des dist-Verzeichnisses live auf unserer Website bereitgestellt wird.

Änderungen zu GitHub committen

Dieser Abschnitt bringt Sie so weit, Ihren Code in einem Git-Repository zu speichern, aber es ist weit entfernt von einem Git-Tutorial. Es gibt viele großartige Tutorials und Bücher, und unsere Git und GitHub-Seite ist ein guter Ausgangspunkt.

Wir haben unser Arbeitsverzeichnis bereits als Git-Arbeitsverzeichnis initialisiert. Eine schnelle Möglichkeit, dies zu überprüfen, besteht darin, den folgenden Befehl auszuführen:

git status

Sie sollten einen Statusbericht erhalten, welche Dateien verfolgt werden, welche Dateien bereit sind usw. — alles Begriffe, die Teil der Git-Grammatik sind. Wenn Sie den Fehler fatal: not a git repository erhalten, dann ist das Arbeitsverzeichnis kein Git-Arbeitsverzeichnis und Sie müssen Git mit git init initialisieren.

Jetzt haben wir drei Aufgaben vor uns:

• Alle Änderungen, die wir gemacht haben, zur Staging hinzuzufügen (ein spezieller Name für den Ort, von dem Git Dateien committet).
• Die Änderungen ins Repository committen.
• Die Änderungen auf GitHub pushen.

1. Um Änderungen hinzuzufügen, führen Sie den folgenden Befehl aus:

   bash

   git add .
   

   Beachten Sie den Punkt am Ende, er bedeutet "alles in diesem Verzeichnis". Der git add .-Befehl ist eine Art Vorschlaghammer-Methode — er fügt alle lokalen Änderungen, an denen Sie gearbeitet haben, auf einmal hinzu. Wenn Sie feinere Kontrolle darüber wünschen, was Sie hinzufügen, verwenden Sie git add -p für einen interaktiven Prozess oder fügen Sie einzelne Dateien mit git add path/to/file hinzu.

2. Jetzt, da der gesamte Code bereitgestellt ist, können wir committen; führen Sie den folgenden Befehl aus:

   bash

   git commit -m 'committing initial code'
   

   Hinweis: Obwohl Sie im Commit-Nachricht schreiben können, was Sie möchten, gibt es im Web einige nützliche Tipps zu guten Commit-Nachrichten. Halten Sie sie kurz, prägnant und beschreibend, damit sie klar beschreiben, was die Änderung bewirkt.

3. Schließlich muss der Code auf das auf GitHub gehostete Repository gepusht werden. Lassen Sie uns das jetzt tun.

   Besuchen Sie auf GitHub https://github.com/new und erstellen Sie Ihr eigenes Repository, um diesen Code zu hosten.

4. Geben Sie Ihrem Repository einen kurzen, einprägsamen Namen, ohne Leerzeichen (trennen Sie Wörter durch Bindestriche), und eine Beschreibung, dann klicken Sie unten auf der Seite auf Create repository.

   Sie sollten jetzt eine "Remote"-URL haben, die auf Ihr neues GitHub-Repo verweist.

   

5. Dieser entfernte Standort muss unserem lokalen Git-Repository hinzugefügt werden, bevor wir es dort hochladen können, andernfalls wird es nicht in der Lage sein, es zu finden. Sie müssen einen Befehl mit der folgenden Struktur ausführen (verwenden Sie die bereitgestellte HTTPS-Option für den Moment — insbesondere, wenn Sie neu bei GitHub sind — nicht die SSH-Option):

   bash

   git remote add origin https://github.com/your-name/repo-name.git
   

   Wenn Ihre Remote-URL also https://github.com/remy/super-website.git war, wie im obigen Screenshot, wäre Ihr Befehl

   bash

   git remote add origin https://github.com/remy/super-website.git
   

   Ändern Sie die URL in Ihr eigenes Repository und führen Sie es jetzt aus.

   Hinweis: Nachdem Sie Ihren Repositoriumsnamen gewählt haben, stellen Sie sicher, dass die base-Option in Ihrer vite.config.js diesen Namen widerspiegelt, wie im vorherigen Kapitel erwähnt. Andernfalls werden die JavaScript- und CSS-Ressourcen nicht korrekt verlinkt.

6. Nun sind wir bereit, unseren Code auf GitHub zu pushen; führen Sie den folgenden Befehl jetzt aus:

   bash

   git push origin main
   

   An dieser Stelle werden Sie aufgefordert, einen Benutzernamen und ein Passwort einzugeben, bevor Git den Push zulässt. Dies liegt daran, dass wir die HTTPS-Option anstelle der SSH-Option verwendet haben, wie im Screenshot zuvor gesehen. Dafür benötigen Sie Ihren GitHub-Benutzernamen und dann — wenn Sie keine Zwei-Faktor-Authentifizierung (2FA) aktiviert haben — Ihr GitHub-Passwort. Wir würden immer empfehlen, 2FA zu verwenden, falls möglich, aber beachten Sie, dass Sie, wenn Sie dies tun, auch ein "Personal Access Token" verwenden müssen. Die Hilfeseiten von GitHub bieten ein ausgezeichnetes und einfaches Tutorial, das beschreibt, wie Sie eines erhalten.

Dieser letzte Befehl weist Git an, den Code an den "Remote"-Standort zu pushen, den wir origin genannt haben (das ist das Repository, das auf github.com gehostet wird — wir hätten es nennen können, wie wir möchtest), unter Verwendung des Zweigs main. Wir sind bisher nicht auf Zweige gestoßen, aber der "main"-Zweig ist der Standardarbeitsplatz für unser Projekt und ist es, wo Git startet. Wenn wir die Aktion definieren, die zum Erstellen der Website ausgelöst wird, lassen wir sie auch nach Änderungen im "main"-Zweig Ausschau halten.

Nachdem unser Projekt in Git commitet und auf unser GitHub-Repository gepusht wurde, ist der nächste Schritt in der Toolchain, eine Build-Aktion zu definieren, damit unser Projekt live im Internet bereitgestellt werden kann!

Verwenden von GitHub Actions für die Bereitstellung

GitHub Actions, wie die ESLint-Konfiguration, ist ein weiteres tiefes Thema, in das man eintauchen kann. Es ist nicht einfach, es beim ersten Versuch richtig zu machen, aber für beliebte Aufgaben wie "eine statische Webseite erstellen und auf GitHub Pages bereitstellen" gibt es viele Beispiele zum Kopieren und Einfügen. Sie können den Anweisungen in Veröffentlichung mit einem benutzerdefinierten GitHub Actions-Workflow folgen. Sie können unsere GitHub Action Datei für ein funktionierendes Beispiel überprüfen. (Der Dateiname spielt keine Rolle.)

Nachdem Sie diese Datei im Hauptzweig committet haben, sollten Sie ein kleines grünes Häkchen neben dem Commit-Titel sehen:

Wenn Sie einen gelben Punkt sehen, bedeutet dies, dass die Aktion läuft, und wenn Sie ein rotes Kreuz sehen, bedeutet dies, dass die Aktion fehlgeschlagen ist. Klicken Sie auf das Symbol, und Sie können den Status und die Protokolle Ihrer eigenen Build-Aktion anzeigen (in unserem Fall "Deploy build" genannt).

Nachdem Sie ein paar Minuten gewartet haben, können Sie Ihre GitHub Pages URL besuchen, um Ihre Webseite live im Web zu sehen. Der Link sieht aus wie https://<Ihr-Name>.github.io/<repo-name>. Für unser Beispiel ist es https://mdn.github.io/client-toolchain-example/.

Nun der letzte Link in unserer Toolchain: ein Test, um sicherzustellen, dass unser Code funktioniert.

Testen

Das Testen an sich ist ein umfangreiches Thema, sogar im Bereich der Front-End-Entwicklung. Ich werde Ihnen zeigen, wie Sie einen ersten Test zu Ihrem Projekt hinzufügen und wie Sie den Test verwenden, um zu verhindern oder zu erlauben, dass das Projekt bereitgestellt wird.

Beim Herangehen an Tests gibt es viele Möglichkeiten, das Problem anzugehen:

• End-to-End-Tests, die beinhalten, dass ein Besucher auf etwas klickt und etwas anderes passiert.
• Integrationstests, die im Grunde fragen: "Funktioniert ein Codeblock immer noch, wenn er mit einem anderen Block verbunden ist?"
• Unit-Tests, bei denen kleine und spezifische Funktionalitäten getestet werden, um zu sehen, ob sie das tun, was sie sollen.
• Und viele weitere Arten. Siehe auch unser Cross-Browser-Testmodul für viele nützliche Testinformationen.

Denken Sie auch daran, dass Tests nicht auf JavaScript beschränkt sind; Tests können gegen das gerenderte DOM, Benutzerinteraktionen, CSS und sogar das Aussehen einer Seite durchgeführt werden.

Für dieses Projekt werden wir jedoch einen kleinen Test erstellen, der überprüft, ob die GitHub-API-Daten im richtigen Format vorliegen. Wenn nicht, schlägt der Test fehl und verhindert, dass das Projekt live geht. Mehr zu tun wäre über den Rahmen dieses Moduls hinaus — das Testen ist ein riesiges Thema, das wirklich ein eigenes Modul erfordert. Wir hoffen, dass dieser Abschnitt zumindest das Bewusstsein für die Notwendigkeit des Testens schafft und den Samen pflanzt, der Sie inspiriert, mehr zu lernen.

Der Test selbst ist nicht das, was wichtig ist. Was wichtig ist, ist, wie das Scheitern oder der Erfolg gehandhabt wird. Da wir bereits eine benutzerdefinierte Build-Aktion schreiben, können wir vor dem Build einen Schritt hinzufügen, der den Test ausführt. Wenn der Test fehlschlägt, wird der Build fehlschlagen und die Bereitstellung wird nicht erfolgen.

Die gute Nachricht ist: Da wir Vite verwenden, bietet Vite bereits ein gutes integriertes Tool zum Testen: Vitest.

Lassen Sie uns beginnen.

1. Installieren Sie Vitest:

   bash

   npm install --save-dev vitest
   

2. Finden Sie in Ihrer package.json Ihr scripts-Mitglied, und aktualisieren Sie es so, dass es die folgenden Test- und Build-Befehle enthält:

   json

   {
     "scripts": {
       // …
       "test": "vitest"
     }
   }
   

   Hinweis: Hier ist der Vorteil der Verwendung von Vite zusammen mit Vitest: Wenn Sie andere Test-Frameworks verwenden, müssen Sie eine zusätzliche Konfiguration hinzufügen, die beschreibt, wie die Testdateien transformiert werden müssen, aber Vitest wird automatisch die Vite-Konfiguration verwenden.

3. Nun müssen wir natürlich den Test in unseren Codebestand aufnehmen. Normalerweise, wenn Sie die Funktionalität einer Datei testen, z. B. App.jsx, würden Sie eine Datei namens App.test.jsx daneben hinzufügen. In diesem Fall testen wir nur die Daten, also lassen Sie uns ein weiteres Verzeichnis erstellen, um unsere Tests zu halten. Sie können das Beispielsrepository öffnen, das Sie im vorherigen Kapitel heruntergeladen haben, und den tests-Ordner darüber kopieren.

4. Nun, um den Test manuell auszuführen, können wir auf der Befehlszeile ausführen:

   bash

   npm run test
   

   Sie sollten eine Ausgabe wie diese sehen:

   > client-toolchain-example@1.0.0 test
   > vitest
   
   
   DEV  v1.6.0 /Users/joshcena/Desktop/work/Tech/projects/mdn/client-toolchain-example
   
   ✓ tests/api.test.js (1) 896ms
     ✓ GitHub API returns the right response 896ms
   
   Test Files  1 passed (1)
        Tests  1 passed (1)
     Start at  23:12:25
     Duration  1.03s (transform 15ms, setup 0ms, collect 5ms, tests 896ms, environment 0ms, prepare 38ms)
   
   
   PASS  Waiting for file changes...
         press h to show help, press q to quit
   

   Das bedeutet, dass der Test bestanden wurde. Genau wie Vite wird es auf Änderungen achten und die Tests neu ausführen, wenn Sie eine Datei speichern. Wir können mit q beenden.

5. Wir müssen den Test jedoch noch mit unserer Build-Aktion verbinden, damit er den Build blockiert, wenn der Test fehlschlägt. Öffnen Sie die Datei .github/workflows/github-pages.yml (oder welchen Dateinamen Sie auch immer Ihrer Build-Aktion gegeben haben) und fügen Sie den folgenden Schritt hinzu, direkt vor dem Schritt, der npm run build ausführt:

   yaml

   - name: Install deps
     run: npm ci
   
   # Add this
   - name: Run tests
     run: npm run test
   
   - name: Build
     run: npm run build
   

   Dies wird den Test vor dem Build-Schritt ausführen. Wenn der Test fehlschlägt, wird der Build fehlschlagen und die Bereitstellung wird nicht erfolgen.

6. Lassen Sie uns jetzt den neuen Code auf GitHub hochladen, indem Sie ähnliche Befehle wie zuvor verwenden:

   bash

   git add .
   git commit -m 'adding test'
   git push origin main
   

   In manchen Fällen möchten Sie das Ergebnis des gebauten Codes testen (da dies nicht ganz der ursprüngliche Code ist, den wir geschrieben haben), daher muss der Test möglicherweise nach dem Build-Befehl ausgeführt werden. Sie werden alle diese individuellen Aspekte berücksichtigen müssen, während Sie an Ihren eigenen Projekten arbeiten.

Schließlich, nachdem Sie gepusht haben, wird GitHub Pages das Projekt-Update in einer Minute oder so bereitstellen. Aber nur, wenn es den eingeführten Test bestanden hat.

Zusammenfassung

Das war's für unsere Beispiel-Fallstudie und für das Modul! Wir hoffen, Sie fanden es nützlich. Auch wenn es noch ein weiter Weg ist, bevor Sie sich als Client-Side-Tooling-Experte betrachten können, hoffen wir, dass dieses Modul Ihnen den ersten wichtigen Schritt in Richtung Verständnis von Client-Side-Tooling gegeben hat und das Vertrauen, mehr zu lernen und Neues auszuprobieren.

Lassen Sie uns alle Teile der Toolchain zusammenfassen:

• Codequalität und Wartung werden von ESLint und Prettier durchgeführt. Diese Tools werden als devDependencies mithilfe von npm install --dev eslint prettier eslint-plugin-react ... (das ESLint-Plugin ist erforderlich, da dieses spezielle Projekt React verwendet) zum Projekt hinzugefügt.
• Es gibt zwei Konfigurationsdateien, die von den Codequalitätstools gelesen werden: eslint.config.js und .prettierrc.
• Während der Entwicklung fügen wir weiterhin Abhängigkeiten mit npm hinzu. Der Vite-Entwicklungsserver wird im Hintergrund ausgeführt, um auf Änderungen zu achten und unsere Quelle automatisch zu erstellen.
• Die Bereitstellung erfolgt durch das Pushen unserer Änderungen auf GitHub (im Hauptzweig), was eine Build- und Bereitstellung mithilfe von GitHub Actions auslöst, um das Projekt bereitzustellen. Für unser Beispiel ist diese URL https://mdn.github.io/client-toolchain-example/; Sie werden Ihre eigene eindeutige URL haben.
• Wir haben auch einen einfachen Test, der den Build und die Bereitstellung der Website blockiert, wenn der GitHub-API-Feed uns nicht das richtige Datenformat liefert.

Für diejenigen, die eine Herausforderung suchen, überlegen Sie, ob Sie einen Teil dieser Toolchain optimieren können. Einige Fragen, die Sie sich stellen sollten:

• Können wir nur die Funktionen von plotly.js extrahieren, die wir benötigen? Dies wird die Größe des JavaScript-Bundles reduzieren.
• Vielleicht möchten Sie weitere Tools hinzufügen, wie TypeScript für Typüberprüfung oder stylelint für CSS-Linting?
• Könnte React durch etwas Kleineres ersetzt werden?
• Könnten Sie weitere Tests hinzufügen, um zu verhindern, dass ein schlechter Build bereitgestellt wird, wie Leistungsaudits?
• Könnten Sie eine Benachrichtigung einrichten, die Sie informiert, wenn eine neue Bereitstellung erfolgreich war oder fehlgeschlagen ist?

• Zurück
• Übersicht: Verständnis der Tools für die clientseitige Webentwicklung