Bereitstellung unserer App

In diesem Abschnitt des Projektlebenszyklus gibt es potenziell eine Vielzahl von Problemen zu lösen. Daher ist es wichtig, eine Toolchain zu erstellen, die diese Probleme mit möglichst wenig manuellen Eingriffen löst.

Hier sind nur ein paar Dinge, die für dieses spezielle Projekt zu berücksichtigen sind:

• Erstellen eines Produktions-Builds: Sicherstellen, dass Dateien minimiert, gestückelt, mit Tree-Shaking versehen und "Cache gebustet" sind.
• Ausführen von Tests: Diese können von "ist der Code richtig formatiert?" bis "erfüllt dieses Ding meine Erwartungen?" reichen und sicherstellen, dass bei fehlschlagenden Tests keine Bereitstellung erfolgt.
• Tatsächliche Bereitstellung des aktualisierten Codes auf einer Live-URL: Oder möglicherweise eine Staging-URL, sodass es zuerst überprüft werden kann.

Die oben genannten Aufgaben lassen sich auch in weitere Aufgaben unterteilen; beachten Sie, dass die meisten Webentwicklungsteams eigene Begriffe und Prozesse für zumindest einige Teilbereiche der Nachentwicklungsphase haben.

Für dieses Projekt nutzen wir das kostenlose Angebot für statisches Hosting von GitHub Pages, um unser Projekt zu hosten. Es sorgt nicht nur dafür, dass unsere Website im Internet bereitgestellt wird, sondern gibt uns auch eine URL zu unserer Website. Das ist großartig — viele MDN-Beispiel-Websites sind auf GitHub Pages gehostet.

Die Bereitstellung für das Hosting erfolgt tendenziell am Ende des Projektlebenszyklus. Mit Diensten wie GitHub Pages, die die Kosten für Bereitstellungen (sowohl finanziell als auch in Bezug auf die tatsächlich erforderliche Zeit) reduzieren, ist es jedoch möglich, während der Entwicklung bereitzustellen, um entweder an Work-in-Progress zu teilen oder um aus einem anderen Grund eine Vorabveröffentlichung zu machen.

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 in den Hauptzweig erfolgt, der den Code baut und an einem bestimmten Ort ablegt.
• GitHub Pages stellt den Code dann unter einer bestimmten URL bereit.

Genau nach solchen verbundenen Diensten sollten Sie suchen, wenn Sie Ihre eigene Toolchain erstellen. Wir können unseren Code commiten und auf GitHub pushen, und der aktualisierte Code wird automatisch den gesamten Build-Prozess auslösen. Wenn alles in Ordnung ist, wird eine Live-Änderung automatisch bereitgestellt. Die einzige Aktion, die wir ausführen müssen, ist der initiale "Push".

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

Da wir Vite für die Entwicklung nutzen, ist die Option zum Bauen sehr einfach hinzuzufügen. Wie wir bereits gesehen haben, haben wir ein benutzerdefiniertes Skript npm run build, das es Vite ermöglicht, alles bereit für die Produktion zu bauen, anstatt es nur für Entwicklungs- und Testzwecke auszuführen. Dazu gehören Minifizierung und Tree-Shaking des Codes sowie Cache-Busting bei Dateinamen.

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

Der neu erstellte Produktionscode wird in einem neuen Verzeichnis namens dist abgelegt, das alle erforderlichen Dateien enthält, um die Website auszuführen, bereit zum Hochladen auf einen Server.

Dieser Schritt manuell auszuführen, ist jedoch nicht unser Endziel - wir möchten, dass der Build automatisch erfolgt und das Ergebnis des dist-Verzeichnisses live auf unserer Website bereitgestellt wird.

Dieser Abschnitt wird Ihnen helfen, Ihren Code in einem Git-Repository zu speichern, ist jedoch noch weit von einem vollständigen Git-Tutorial entfernt. Es gibt viele großartige Tutorials und Bücher, und unsere Git und GitHub-Seite ist ein guter Startpunkt.

Wir haben unser Arbeitsverzeichnis bereits als Git-Arbeitsverzeichnis initialisiert. Ein schneller Weg, dies zu überprüfen, ist, den folgenden Befehl auszuführen:

git status

Sie sollten einen Statusbericht erhalten, welche Dateien verfolgt werden, welche Dateien bereitgestellt sind usw. — alles Begriffe, die zur Git-Grammatik gehören. 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 liegen drei Aufgaben vor uns:

• Alle Änderungen, die wir vorgenommen haben, zur Bühne hinzufügen (ein spezieller Ort, von dem Git Dateien commiten wird).
• Die Änderungen ins Repository committen.
• Die Änderungen zu GitHub pushen.

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

   bashCopy to Clipboard

   git add .
   

   Beachten Sie den Punkt am Ende, er bedeutet "alles in diesem Verzeichnis". Der Befehl git add . ist ein umfassender Ansatz — er wird alle lokalen Änderungen, an denen Sie gearbeitet haben, auf einmal hinzufügen. Wenn Sie eine feinere Kontrolle darüber haben möchten, 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:

   bashCopy to Clipboard

   git commit -m 'committing initial code'
   

   Hinweis: Obwohl Sie frei sind, im Commit-Kommentar zu schreiben, was Sie möchten, gibt es im Web einige nützliche Tipps zu guten Commit-Kommentaren. Halten Sie sie kurz, prägnant und beschreibend, sodass sie klar beschreiben, was die Änderung bewirkt.

3. Endlich, der Code muss zu Ihrem auf GitHub gehosteten Repository gepusht werden. Lassen Sie uns das jetzt tun.

   Besuchen Sie bei 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 (verwenden Sie Bindestriche für die Trennung von Wörtern) und eine Beschreibung, und klicken Sie dann auf Create repository am unteren Rand der Seite.

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

   

5. Dieser Remote-Standort muss unserem lokalen Git-Repository hinzugefügt werden, bevor wir es hochpushen können, ansonsten kann er es nicht finden. Sie müssen einen Befehl mit der folgenden Struktur ausführen (verwenden Sie vorerst die bereitgestellte HTTPS-Option — besonders wenn Sie neu bei GitHub sind — nicht die SSH-Option):

   bashCopy to Clipboard

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

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

   bashCopy to Clipboard

   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 Repository-Namen ausgewä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 zu GitHub zu pushen; führen Sie den folgenden Befehl jetzt aus:

   bashCopy to Clipboard

   git push origin main
   

   Zu diesem Zeitpunkt 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 früheren Screenshot zu sehen war. 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, wenn möglich, jedoch bedenken Sie, dass Sie, falls Sie dies tun, auch ein "persönliches Zugriffstoken" verwenden müssen. GitHub-Hilfeseiten bieten einen ausgezeichneten und einfachen Leitfaden, der beschreibt, wie man eines erhält.

Dieser letzte Befehl weist Git an, den Code an den "Remote" Standort zu pushen, den wir origin genannt haben (das Repository, das auf github.com gehostet ist — wir könnten es nennen, wie wir wollen) unter Verwendung des Zweigs main. Wir haben bisher keine Zweige behandelt, aber der "main"-Zweig ist der Standardort für unsere Arbeit, und dort startet Git. Wenn wir die Aktion definieren, die ausgelöst wird, um die Website zu bauen, lassen wir sie ebenfalls auf Änderungen im "main"-Zweig achten.

Mit unserem Projekt, das in Git committet und in unser GitHub-Repository gepusht wurde, ist der nächste Schritt in der Toolchain die Definition einer Build-Aktion, damit unser Projekt live im Web bereitgestellt werden kann!

GitHub Actions, ähnlich wie die ESLint-Konfiguration, ist ein weiteres tiefes Thema, in das man eintauchen kann. Es ist nicht leicht, es beim ersten Mal richtig zu machen, aber für beliebte Aufgaben wie "eine statische Website bauen und auf GitHub Pages bereitstellen" gibt es viele Beispiele, aus denen man kopieren und einfügen kann. Sie können die Anweisungen in Veröffentlichen mit einem benutzerdefinierten GitHub-Actions-Workflow befolgen. Sie können auch unsere GitHub Action-Datei für ein funktionierendes Beispiel einsehen. (Der Name der Datei spielt keine Rolle.)

Nachdem Sie diese Datei in den Hauptzweig committen, sollten Sie ein kleines grünes Häkchen neben dem Commit-Titel sehen:

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

Nach ein paar weiteren Minuten können Sie Ihre GitHub Pages-URL besuchen, um Ihre Website live im Web zu sehen. Der Link sieht in etwa so aus: https://<your-name>.github.io/<repo-name>. In unserem Beispiel ist es unter https://mdn.github.io/client-toolchain-example/.

Nun zum letzten Element in unserer Toolchain: ein Test, um sicherzustellen, dass unser Code funktioniert.

Testen ist ein umfangreiches Thema, selbst im Bereich der Frontend-Entwicklung. Ich zeige Ihnen, wie Sie einen ersten Test zu Ihrem Projekt hinzufügen und wie Sie den Test nutzen können, um die Projektbereitstellung zu ermöglichen oder zu verhindern.

Beim Testen gibt es viele Ansätze, das Problem zu behandeln:

• End-to-End-Tests, bei denen Ihr Besucher etwas anklickt und etwas anderes passiert.
• Integrationstests, die im Grunde sagen "funktioniert ein Codeblock 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 Testarten. Siehe auch unser Cross-Browser-Testing-Modul für eine Menge nützlicher Testinformationen.

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

Für dieses Projekt erstellen wir jedoch einen kleinen Test, 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. Alles andere wäre über den Rahmen dieses Moduls hinaus - Testen ist ein riesiges Thema, das wirklich ein eigenes Modul benötigt. Wir hoffen, dass dieser Abschnitt Sie zumindest auf die Notwendigkeit von Tests aufmerksam macht und den Anstoß gibt, mehr zu lernen.

Der Test selbst ist nicht das Wichtigste. Wichtig ist, wie das Scheitern oder Bestehen gehandhabt wird. Da wir ohnehin eine benutzerdefinierte Build-Aktion schreiben, können wir einen Schritt vor dem Build hinzufügen, der den Test ausführt. Schlägt der Test fehl, schlägt auch der Build fehl, und die Bereitstellung erfolgt nicht.

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

Lassen Sie uns beginnen.

1. Installieren Sie Vitest:

   bashCopy to Clipboard

   npm install --save-dev vitest
   

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

   jsonCopy to Clipboard

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

   Hinweis: Das ist der gute Teil bei der Verwendung von Vite zusammen mit Vitest: Bei Verwendung anderer Testframeworks müssen Sie eine weitere Konfiguration hinzufügen, die beschreibt, wie die Testdateien transformiert werden müssen, aber Vitest wird automatisch die Vite-Konfiguration verwenden.

3. Natürlich müssen wir den Test in unseren Code einfügen. Normalerweise würden Sie, wenn Sie die Funktionalität einer Datei, sagen wir App.jsx, testen, eine Datei namens App.test.jsx daneben hinzufügen. In diesem Fall testen wir nur die Daten, also erstellen wir ein anderes Verzeichnis, um unsere Tests zu speichern. Sie können das Beispiel-Repository, das Sie im vorherigen Kapitel heruntergeladen haben, öffnen und den Ordner tests kopieren.

4. Um den Test manuell auszuführen, können wir folgendes von der Kommandozeile ausführen:

   bashCopy to Clipboard

   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
   

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

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

   yamlCopy to Clipboard

   - 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, schlägt der Build ebenfalls fehl, und die Bereitstellung wird nicht durchgeführt.

6. Lassen Sie uns den neuen Code zu GitHub hochladen, mit ähnlichen Befehlen wie zuvor:

   bashCopy to Clipboard

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

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

Schließlich, eine Minute oder so nach dem Pushen, wird GitHub Pages das Projekt-Update bereitstellen. Aber nur, wenn es den neu eingeführten Test besteht.

Das war's für unsere Beispiel-Fallstudie und für das Modul! Wir hoffen, Sie fanden es nützlich. Während es noch ein langer Weg ist, bevor Sie sich selbst als Experte für Clientseitige Tools betrachten können, hoffen wir, dass Ihnen dieses Modul den ersten wichtigen Schritt zum Verständnis von clientseitigen Tools gegeben hat und das Vertrauen, mehr zu lernen und neue Dinge 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 zum Projekt hinzugefügt über npm install --dev eslint prettier eslint-plugin-react ... (das ESLint-Plugin ist erforderlich, weil dieses spezielle Projekt React verwendet).
• Es gibt zwei Konfigurationsdateien, die die Codequalitäts-Tools lesen: 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 Änderungen zu überwachen und automatisch unseren Quellcode zu bauen.
• Die Bereitstellung erfolgt durch das Hochladen unserer Änderungen auf GitHub (im "main"-Zweig), das eine Build- und Bereitstellungsaktion auslöst, um das Projekt zu veröffentlichen. Für unser Beispiel ist diese URL https://mdn.github.io/client-toolchain-example/; Sie werden Ihre eigene einzigartige URL haben.
• Wir haben auch einen einfachen Test, der das Bauen und Bereitstellen der Seite blockiert, wenn das GitHub-API-Feed uns nicht das richtige Datenformat gibt.

Für diejenigen von Ihnen, 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? Dadurch wird die JavaScript-Bundlegröße reduziert.
• Vielleicht möchten Sie andere Tools hinzufügen, wie TypeScript zur 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 einen schadhaften Build von der Bereitstellung abzuhalten, wie Leistungs-Audits?
• Könnten Sie eine Benachrichtigung einrichten, um Ihnen mitzuteilen, wenn eine neue Bereitstellung erfolgreich war oder fehlgeschlagen ist?

• Zurück
• Übersicht: Verständnis von Client-seitigen Webentwicklungstools