Deployment unserer App

Nach der Entwicklung

Es gibt möglicherweise eine große Anzahl an Problemen, die in dieser Phase des Projektlebenszyklus gelöst werden müssen. Daher ist es wichtig, eine Toolchain zu erstellen, die diese Probleme so automatisiert wie möglich behandelt.

Hier sind einige Dinge, die Sie bei diesem speziellen Projekt in Betracht ziehen sollten:

• Erstellen eines Produktions-Builds: Sicherstellen, dass Dateien minimiert, aufgeteilt, Tree-Shaking angewendet und Versionen „Cache-busting“ unterzogen werden.
• Tests durchführen: Diese reichen von „ist dieser Code richtig formatiert?“ bis „macht diese Funktion, was ich erwarte?“ und dafür sorgen, dass fehlschlagende Tests die Bereitstellung verhindern.
• Tatsächliche Bereitstellung des aktualisierten Codes auf einer Live-URL: Oder möglicherweise einer Staging-URL, damit er zuerst überprüft werden kann.

Die oben genannten Aufgaben lassen sich auch in weitere Aufgaben unterteilen; beachten Sie dabei, dass die meisten Web-Entwicklungsteams ihre eigenen Begriffe und Prozesse für mindestens einen Teil der Post-Entwicklungsphase haben.

Für dieses Projekt verwenden wir GitHub Pages's kostenloses Angebot für statisches Hosting, um unser Projekt zu hosten. Es dient nicht nur der Bereitstellung unserer Website im Internet, sondern gibt uns auch eine URL zu unserer Website. Es ist großartig – viele MDN-Beispiel-Websites werden auf GitHub Pages gehostet.

Die Bereitstellung beim Hosting tendiert dazu, das letzte Ende des Projektlebenszyklus zu sein. Mit Diensten wie GitHub Pages, die die Kosten für Bereitstellungen sowohl in finanzieller Hinsicht als auch in der tatsächlich benötigten Zeit reduzieren, ist es möglich, während der Entwicklung Bereitstellungen durchzuführen, um Arbeiten in Arbeit zu teilen oder eine Vorabveröffentlichung zu einem anderen Zweck zu haben.

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

• Sie übertragen Ihren Code zu GitHub.
• Sie definieren eine GitHub Action, die ausgelöst wird, wenn ein neuer Push in den Hauptbranch erfolgt, der den Code erstellt und an einem bestimmten Ort platziert.
• GitHub Pages stellt dann den Code an einer bestimmten URL bereit.

Es sind genau diese Arten von verbundenen Diensten, die wir Ihnen ans Herz legen würden, wenn Sie sich für Ihre eigene Build-Toolchain entscheiden. Wir können unseren Code einchecken und zu GitHub pushen, und der aktualisierte Code löst automatisch die gesamte Build-Routine aus. Wenn alles gut geht, wird eine Live-Änderung automatisch bereitgestellt. Die einzige Aktion, die wir ausführen müssen, ist dieser anfängliche „Push“.

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

Der Build-Prozess

Wieder einmal, da wir Vite für die Entwicklung verwenden, ist die Hinzufügung der Build-Option äußerst einfach. Wie wir bereits gesehen haben, haben wir ein benutzerdefiniertes Skript npm run build, das Vite alles für die Produktion erstellen lässt, anstatt es nur für Entwicklungs- und Testzwecke auszuführen. Dazu gehören Minimierung und Tree-Shaking des Codes sowie Cache-Busting bei Dateinamen.

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

Der neu erstellte Produktionscode wird in einem neuen Verzeichnis namens dist platziert, das alle Dateien enthält, die zum Ausführen der Website erforderlich sind, und bereit, um sie auf einen Server hochzuladen.

Allerdings ist es nicht unser Endziel, diesen Schritt manuell zu machen – was wir wollen, ist, dass der Build automatisch erfolgt und das Ergebnis des dist-Verzeichnisses live auf unserer Website bereitgestellt wird.

Änderungen in GitHub einbringen

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

Wir haben unser Arbeitsverzeichnis bereits früher 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 überwacht werden, welche Dateien bereitgestellt sind usw. – alles Begriffe, die Teil der git-Grammatik sind. Wenn Ihnen der Fehler fatal: not a git repository angezeigt wird, dann ist das Arbeitsverzeichnis kein git-Arbeitsverzeichnis, und Sie müssen git mit git init initialisieren.

Nun haben wir drei Aufgaben vor uns:

• Alle Änderungen, die wir vorgenommen haben, zur Staging-Phase hinzufügen (ein besonderer Name für den Ort, von dem aus git Dateien festschreiben wird).
• Die Änderungen im Repository festschreiben.
• Die Änderungen zu 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 Befehl git add . ist eine Art Holzhammer-Ansatz – er wird alle lokalen Änderungen, an denen Sie gearbeitet haben, auf einmal hinzufügen. 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. Da jetzt der gesamte Code bereitgestellt ist, können wir ihn festschreiben; führen Sie den folgenden Befehl aus:

   bash

   git commit -m 'committing initial code'
   

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

3. Schließlich muss der Code in Ihr auf GitHub gehostetes Repository gepusht werden. Lassen Sie uns das nun tun.

   Besuchen Sie GitHub unter 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 darin (verwenden Sie Bindestriche, um Wörter zu trennen), und eine Beschreibung, und klicken Sie dann unten auf der Seite auf Create repository.

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

   

5. Diese Remote-Location muss unserem lokalen git-Repository hinzugefügt werden, bevor wir es hochladen können, ansonsten kann es nicht gefunden werden. Sie müssen einen Befehl mit der folgenden Struktur ausführen (verwenden Sie vorerst die bereitgestellte HTTPS-Option – 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 https://github.com/remy/super-website.git wäre, 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 Repository-Namen 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-Assets nicht korrekt verlinkt.

6. Jetzt sind wir bereit, unseren Code zu GitHub hochzuladen; führen Sie nun den folgenden Befehl aus:

   bash

   git push origin main
   

   An diesem Punkt werden Sie dazu aufgefordert, einen Benutzernamen und ein Passwort einzugeben, bevor Git erlaubt, den Push zu senden. Dies liegt daran, dass wir die HTTPS-Option anstatt der SSH-Option verwendet haben, wie im Screenshot zuvor gezeigt. Dafür brauchen Sie Ihren GitHub-Benutzernamen und dann – wenn Sie keine Zwei-Faktor-Authentifizierung (2FA) aktiviert haben – Ihr GitHub-Passwort. Wir würden Ihnen immer empfehlen, 2FA zu verwenden, wenn möglich, aber beachten Sie, dass, wenn Sie dies tun, auch ein „Personal Access Token“ benötigt wird. Die Hilfeseiten von GitHub haben eine ausgezeichnete und einfache Anleitung, wie man eines erhält.

Dieser abschließende Befehl weist git an, den Code an die "Remote"-Location zu senden, die wir origin genannt haben (das ist das auf github.com gehostete Repository – wir hätten es nennen können, wie wir wollten) und dabei den Branch main zu verwenden. Wir sind dabei noch nicht auf Branches gestoßen, aber der "main"-Branch ist der Standardort für unsere Arbeit und es ist der, auf dem git beginnt. Wenn wir die Aktion definieren, die ausgelöst wird, um die Website zu erstellen, lassen wir sie auch auf Änderungen im "main"-Branch achten.

Mit unserem Projekt, das in git festgeschrieben und in unser GitHub-Repository hochgeladen wurde, besteht der nächste Schritt der Toolchain darin, eine Build-Aktion zu definieren, damit unser Projekt live im Web bereitgestellt werden kann!

Verwenden von GitHub Actions für die Bereitstellung

GitHub Actions, ähnlich wie die Konfiguration von ESLint, ist ein weiteres tiefes Kaninchenloch, in das Sie eintauchen können. Es ist nicht einfach, es beim ersten Versuch richtig hinzubekommen, aber für beliebte Aufgaben wie „eine statische Website erstellen und auf GitHub Pages bereitstellen“ gibt es viele Beispiele zum Kopieren und Einfügen. Sie können den Anweisungen unter Veröffentlichen mit einem benutzerdefinierten GitHub Actions-Workflow folgen. Sie können unsere GitHub Action-Datei für ein funktionierendes Beispiel prüfen. (Der Dateiname spielt keine Rolle.)

Nachdem Sie diese Datei im Haupt-Branch festgeschrieben 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 ausgeführt wird, und wenn Sie ein rotes Kreuz sehen, bedeutet es, dass die Aktion fehlgeschlagen ist. Klicken Sie auf das Symbol, um den Status und die Protokolle Ihrer eigenen Build-Aktion zu sehen (in unserem Fall benannt „Deploy build“).

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

Jetzt fehlt noch ein letzter Link in unserer Toolchain: ein Test, um sicherzustellen, dass unser Code ordnungsgemäß funktioniert.

Tests

Das Testen selbst ist ein weites Thema, sogar im Bereich der Front-End-Entwicklung. Ich zeige Ihnen, wie Sie einen ersten Test zu Ihrem Projekt hinzufügen und wie Sie den Test verwenden, um den Projektbereitstellungsprozess zu verhindern oder zu erlauben.

Es gibt viele Ansätze beim Testen:

• End-to-End-Testing, bei dem Ihr 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 tun, was sie sollen.
• Und viele weitere Typen. Siehe auch unser Cross-Browser-Testing-Modul 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 erstellen wir jedoch einen kleinen Test, der überprüft, ob die GitHub-API-Daten im korrekten Format vorliegen. Wenn nicht, schlägt der Test fehl und verhindert, dass das Projekt live geht. Alles andere wäre über den Umfang dieses Moduls hinaus – das Testen ist ein riesiges Thema, das wirklich sein eigenes Modul erfordert. Wir hoffen, dass dieser Abschnitt Sie zumindest auf die Notwendigkeit des Testens aufmerksam macht und die Saat für Ihr Interesse legt, mehr darüber zu erfahren.

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

Die gute Nachricht: Weil wir Vite verwenden, bietet Vite bereits ein gutes integriertes Testwerkzeug an: Vitest.

Lassen Sie uns beginnen.

1. Installieren Sie Vitest:

   bash

   npm install --save-dev vitest
   

2. Suchen Sie in Ihrer package.json nach Ihrem scripts-Mitglied, und aktualisieren Sie es so, dass es die folgenden Test- und Build-Kommandos enthält:

   json

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

   Hinweis: Hier ist der Vorteil, Vite zusammen mit Vitest zu verwenden: 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 zu unserem Code hinzufügen. Normalerweise, wenn Sie die Funktionalität einer Datei testen, sagen wir App.jsx, würden Sie eine Datei namens App.test.jsx neben sie 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 öffnen, das Sie im vorherigen Kapitel heruntergeladen haben, und den Ordner tests kopieren.

4. Um den Test manuell auszuführen, können wir im Befehlszeilenterminal Folgendes 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
   

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

5. Wir müssen immer noch den Test mit unserer Build-Aktion verbinden, sodass er den Build blockiert, wenn der Test fehlschlägt. Öffnen Sie die Datei .github/workflows/github-pages.yml (oder welchen Dateinamen Sie Ihrer Build-Aktion gegeben haben) und fügen Sie den folgenden Schritt hinzu, direkt bevor der Schritt ausgeführt wird, 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 stattfinden.

6. Jetzt laden wir den neuen Code zu GitHub hoch, indem wir ähnliche Befehle verwenden, wie Sie es zuvor getan haben:

   bash

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

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

Zum Schluss, nach einer Minute oder so nach dem Push, wird das Update des Projekts von GitHub Pages bereitgestellt. Aber nur, wenn es den eingeführten Test besteht.

Zusammenfassung

Das war's für unsere Beispiel-Fallstudie und für das Modul! Wir hoffen, Sie fanden es nützlich. Obwohl es noch ein langer Weg ist, bis Sie sich selbst als Client-side-Tooling-Virtuosen bezeichnen können, hoffen wir, dass Ihnen dieses Modul diesen ersten wichtigen Schritt hin zu einem Verständnis für Client-seitige Tools gibt und Ihnen das Selbstbewusstsein vermittelt, mehr zu lernen und neue Dinge auszuprobieren.

Lassen Sie uns alle Teile der Toolchain zusammenfassen:

• Die Codequalität und Wartung erfolgen durch ESLint und Prettier. Diese Tools werden als devDependencies hinzugefügt über npm install --dev eslint prettier eslint-plugin-react ... (das ESLint-Plugin wird benötigt, weil dieses spezielle Projekt React verwendet).
• Es gibt zwei Konfigurationsdateien, die die Codequalitätstools lesen: eslint.config.js und .prettierrc.
• Während der Entwicklung fügen wir weiterhin Abhängigkeiten mit npm hinzu. Der Vite-Entwicklungsserver läuft im Hintergrund, um Änderungen zu überwachen und unseren Quellcode automatisch zu erstellen.
• Die Bereitstellung erfolgt durch das Pushen unserer Änderungen zu GitHub (im "main"-Branch), was durch GitHub Actions einen Build und eine Bereitstellung auslöst, um das Projekt zu veröffentlichen. Für unsere Instanz 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 nicht das richtige Datenformat liefert.

Für diejenigen von Ihnen, die eine Herausforderung suchen, überlegen Sie, ob Sie einige Teile dieser Toolchain optimieren können. Einige Fragen, die Sie sich stellen könnten:

• Können wir nur die Funktionen von plotly.js extrahieren, die wir brauchen? Dies würde die Größe des JavaScript-Bundles reduzieren.
• Vielleicht möchten Sie andere Tools hinzufügen, wie TypeScript für die Typprüfung oder stylelint für CSS-Linting?
• Könnte React durch etwas Kleineres ersetzt werden?
• Könnten Sie weitere Tests hinzufügen, um einen schlechten Build von der Bereitstellung zu verhindern, wie etwa Performance-Audits?
• Könnten Sie eine Benachrichtigung einrichten, die Ihnen mitteilt, wann ein neuer Deploy erfolgreich oder fehlgeschlagen ist?