{"id":65104,"date":"2023-08-21T14:08:01","date_gmt":"2023-08-21T13:08:01","guid":{"rendered":"https:\/\/kinqsta.com\/de\/?p=65104&preview=true&preview_id=65104"},"modified":"2023-08-29T13:41:20","modified_gmt":"2023-08-29T12:41:20","slug":"ci-cd-pipeline-github-aktionen-erstellen","status":"publish","type":"post","link":"https:\/\/kinqsta.com\/de\/blog\/ci-cd-pipeline-github-aktionen-erstellen\/","title":{"rendered":"Wie man eine CI\/CD-Pipeline mit GitHub-Aktionen und der Kinsta-API erstellt"},"content":{"rendered":"

In der schnelllebigen Welt der Webentwicklung<\/a> sind kontinuierliche Integration und kontinuierliche Bereitstellung (CI\/CD<\/a>) zu unverzichtbaren Praktiken f\u00fcr die effiziente Bereitstellung hochwertiger Software geworden. CI\/CD erm\u00f6glicht es Entwicklern, den Prozess des Erstellens, Testens und Verteilens von Code\u00e4nderungen zu automatisieren, das Risiko menschlicher Fehler zu verringern und schnellere Iterationen zu erm\u00f6glichen. In diesem Artikel erf\u00e4hrst du, warum CI\/CD so wichtig ist, wie du eine CI-Pipeline erstellst und wie du die kontinuierliche Bereitstellung in deiner CI-Pipeline mit der Kinsta-API<\/a> programmatisch einrichtest – alles mit GitHub Actions in deinem GitHub<\/a>-Repository.

<\/div><\/kinsta-auto-toc><\/p>\n

Warum CI\/CD?<\/h2>\n

Die Anwendungs-Hosting<\/a>-Plattform von Kinsta bietet seit jeher eine Option f\u00fcr die automatische Bereitstellung, die immer dann ausgel\u00f6st wird, wenn eine \u00c4nderung an einem bestimmten Branch in deinem gehosteten Git-Repository vorgenommen wird. F\u00fcr gro\u00dfe Projekte mit mehreren Teammitgliedern ist dies jedoch nicht unbedingt ideal. Viele Entwickler\/innen<\/a> neigen dazu, die automatische Bereitstellung aus verschiedenen Gr\u00fcnden nicht zu aktivieren.<\/p>\n

Ein Grund daf\u00fcr ist, dass in einer kollaborativen Umgebung, in der mehrere Entwickler\/innen am selben Projekt arbeiten, automatische Verteilungen, die durch die \u00c4nderung eines\/r Entwicklers\/in am Repository ausgel\u00f6st werden, zu Instabilit\u00e4t und unvorhergesehenen Problemen f\u00fchren k\u00f6nnen. Ohne eine ordnungsgem\u00e4\u00dfe Pr\u00fcfung und Validierung kann selbst eine kleine Code\u00e4nderung die Live-Site st\u00f6ren, was zu Ausfallzeiten und negativen Nutzererfahrungen f\u00fchren kann.<\/p>\n

An dieser Stelle kommt eine CI\/CD-Pipeline ins Spiel. Mit einem sorgf\u00e4ltig orchestrierten CI\/CD-Workflow k\u00f6nnen Entwickler\/innen sicherstellen, dass Code\u00e4nderungen getestet und validiert werden, bevor sie auf der Live-Site eingesetzt werden. Es gibt viele Tools f\u00fcr die Implementierung von CI\/CD in der Softwareentwicklung. In diesem Tutorial werden wir GitHub Actions<\/a> verwenden.<\/p>\n

Was ist GitHub Actions?<\/h2>\n

GitHub Actions ist ein leistungsstarkes Automatisierungstool von GitHub. Es bietet Entwicklern die M\u00f6glichkeit, verschiedene Aufgaben, Prozesse und Arbeitsabl\u00e4ufe innerhalb ihrer Softwareentwicklungsprojekte zu automatisieren. Es l\u00e4sst sich in die GitHub-Repositories integrieren und ist daher einfach zu bedienen.<\/p>\n

Mit GitHub Actions und der Kinsta-API<\/a> kannst du benutzerdefinierte Workflows definieren, die zu deinen Projektanforderungen passen. Du kannst eine CI-Pipeline einrichten, die deine Anwendung testet und die Bereitstellung auf Kinsta anst\u00f6\u00dft.<\/p>\n

Erste Schritte mit GitHub Actions<\/h2>\n

GitHub Actions basiert auf dem Konzept der Workflows, d.h. auf automatisierten Aufgaben, die durch bestimmte Ereignisse ausgel\u00f6st oder in regelm\u00e4\u00dfigen Abst\u00e4nden geplant werden. Zu diesen Ereignissen k\u00f6nnen Code-Pushes, Pull-Requests, das Erstellen von Problemen und vieles mehr geh\u00f6ren. Wenn eines dieser Ereignisse eintritt, f\u00fchrt GitHub Actions automatisch einen zugeh\u00f6rigen Workflow aus, der eine Reihe von vordefinierten Schritten ausf\u00fchrt.<\/p>\n

Jeder Schritt im Workflow steht f\u00fcr eine bestimmte Aktion, z. B. das Erstellen des Codes, das Ausf\u00fchren von Tests, das Verteilen oder das Senden von Benachrichtigungen. Lass uns einen Workflow mit drei Aufgaben erstellen:<\/p>\n

    \n
  1. Syntax mit ESLint pr\u00fcfen<\/li>\n
  2. Tests ausf\u00fchren<\/li>\n
  3. Anwendung erneut bereitstellen<\/li>\n<\/ol>\n

    Schritt 1: Richte dein GitHub-Repository ein<\/h3>\n

    Um mit GitHub Actions loszulegen, brauchst du ein GitHub Repository.<\/p>\n

    Hier verwenden wir dieses GitHub-Repository<\/a>, das f\u00fcr das Tutorial How To Build and Deploy a ChatGPT Clone Application With React and OpenAI API<\/a> entwickelt wurde.<\/p>\n

    Du kannst das Repository selbst verwenden, indem du auf GitHub dorthin navigierst und ausw\u00e4hlst: Diese Vorlage verwenden<\/strong> > Ein neues Repository erstellen<\/strong>.<\/p>\n

    In dieser React-Anwendung werden Unit-Tests erstellt, um jede Komponente zu testen. ESLint wird auch verwendet, um eine perfekte Syntax und Codeformatierung zu gew\u00e4hrleisten. Die CI-Pipeline blockiert die Bereitstellung, wenn ein Pull Request oder zusammengef\u00fchrter Code, der in das Repository eingestellt wird, die Workflow-Tests nicht besteht.<\/p>\n

    Schritt 2: Erstellen einer Workflow-Datei<\/h3>\n

    Definiere deinen Workflow, indem du eine YAML-Datei im Verzeichnis .github\/workflows<\/strong> deines Repositorys erstellst. Dieses Verzeichnis sollte sich auf der Stammebene deines Projektarchivs befinden. Die Namenskonvention f\u00fcr Workflow-Dateien ist Name-des-Workflows.yml<\/strong>.<\/p>\n

      \n
    1. Erstelle in deinem Repository ein .github<\/strong>-Verzeichnis.<\/li>\n
    2. Erstelle innerhalb des .github<\/strong>-Verzeichnisses ein neues Verzeichnis namens workflows<\/strong>.<\/li>\n
    3. Im Verzeichnis workflows erstellst du eine neue Datei mit dem Namen build-test-deploy.yml<\/strong>.<\/li>\n<\/ol>\n

      Schritt 3: Schreibe den CI\/CD-Workflow<\/h3>\n

      Nachdem du deine Workflow-Datei erstellt hast, definierst du einen Workflow mit den notwendigen Schritten, um die Syntax mit ESLint zu pr\u00fcfen, Tests durchzuf\u00fchren und die Anwendung einzusetzen.<\/p>\n

      CI-Ereignis erstellen<\/h4>\n

      Wenn du eine CI-Pipeline erstellst, musst du dem Workflow zun\u00e4chst einen Namen geben und dann das Ereignis festlegen, das den Workflow ausl\u00f6sen soll. In diesem Beispiel sind die beiden Ereignisse eine Pull-Anforderung und ein Push auf den Hauptzweig.<\/p>\n

      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"<\/code><\/pre>\n
      Wenn du regelm\u00e4\u00dfige Jobs (CRON-Jobs) f\u00fcr bestimmte Aufgaben planen m\u00f6chtest, kannst du sie dem Workflow hinzuf\u00fcgen. Du k\u00f6nntest zum Beispiel bestimmte Aufgaben wie Datenbanksicherungen, Datenbereinigung oder andere regelm\u00e4\u00dfige Wartungsaufgaben ausf\u00fchren.<\/p>\n
      Hier ist ein Beispiel daf\u00fcr, wie du einen CRON-Job zum Workflow hinzuf\u00fcgen kannst:<\/p>\n
      on:\n  # Existing event triggers for push and pull_request\n\n  # Add a schedule for CRON jobs\n  schedule:\n    - cron: \"0 0 * * *\"<\/code><\/pre>\n
      Im obigen Beispiel wird der Workflow jeden Tag um Mitternacht (UTC-Zeit) ausgel\u00f6st, da der Cron-Zeitplan auf 0 0 * * *<\/code> eingestellt ist. Du kannst den Cron-Zeitplan an deine Bed\u00fcrfnisse anpassen.<\/p>\n
      Ein weiteres Beispiel: Angenommen, du m\u00f6chtest den CI\/CD-Workflow so planen, dass er jeden Montag um 8 Uhr morgens ausgef\u00fchrt wird. Wir k\u00f6nnen einen CRON-Job mit dem Ereignis schedule<\/code> einrichten:<\/p>\n
      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"\n\n  # Schedule the workflow to run every Monday at 8 a.m. (UTC time)\n  schedule:\n    - cron: \"0 8 * * 1\"\n\njobs:\n # Add jobs<\/code><\/pre>\n
      Die Zeitplansyntax, die im schedule<\/code> Event f\u00fcr GitHub Actions Workflows verwendet wird, basiert auf der UNIX cron Syntax. Sie erm\u00f6glicht es dir, bestimmte Zeiten oder Intervalle festzulegen, in denen dein Workflow automatisch ausgef\u00fchrt werden soll. Die Syntax besteht aus f\u00fcnf Feldern, die verschiedene Aspekte des Zeitplans darstellen. Jedes Feld wird durch ein Leerzeichen getrennt. Das allgemeine Format der Zeitplansyntax ist wie folgt:<\/p>\n
      * * * * *\n\u252c \u252c \u252c \u252c \u252c\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of the week (0 - 7) (Sunday to Saturday, where both 0 and 7 represent Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1 - 12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of the month (1 - 31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0 - 23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0 - 59)<\/code><\/pre>\n
      Schauen wir uns die einzelnen Felder an:<\/p>\n