Informationen zur fortlaufenden Integration
Bei der Softwarepraktik der fortlaufenden Integration (CI) erfolgen häufige Code-Commits an ein gemeinsames Repository. Code-Commits in kurzen Abständen tragen dazu bei, Fehler frühzeitiger aufzudecken, und verringern die Codemenge, die ein Entwickler auf der Suche nach der Fehlerursache debuggen muss. Durch häufige Code-Aktualisierungen lassen sich zudem Änderungen von verschiedenen Mitgliedern eines Software-Entwicklungsteams leichter zusammenführen. Dies bedeutet einen erheblichen Vorteil für die Entwickler, die sich damit stärker auf das Schreiben des Codes konzentrieren können, statt Fehler debuggen oder Mergekonflikte beheben zu müssen.
Durch einen Code-Commit an das Repository können Sie den Code fortlaufend erstellen und testen, sodass gewährleistet ist, dass der Commit keine Fehler einbringt. Die Tests können beispielsweise Code-Linters (überprüfen Stilformatierungen), Sicherheitsprüfungen, Code-Abdeckung, Funktionstests und andere benutzerdefinierte Prüfungen umfassen.
Zum Erstellen und Testen des Codes ist ein Server erforderlich. Sie können Aktualisierungen lokal erstellen und testen, bevor Sie den Code per Push an ein Repository senden, oder auch einen CI-Server heranziehen, der neue Code-Commits in einem Repository prüft.
Informationen zur kontinuierlichen Integration mit GitHub Actions
CI mit GitHub Actions bietet Workflows, die den Code in Ihrem Repository erstellen und Ihre Tests ausführen können. Workflows können auf GitHubgehosteten virtuellen Maschinen oder auf Computern ausgeführt werden, die Sie selbst hosten. Weitere Informationen finden Sie unter "Virtuelle Umgebungen für GitHubgehostete Läufer" und "über selbst gehostete Läufer".
Sie können Ihren CI-Workflow so konfigurieren, dass er ausgeführt wird, wenn ein GitHub Ereignis auftritt (z. B. wenn neuer Code an Ihr Repository übertragen wird), nach einem festgelegten Zeitplan oder wenn ein externes Ereignis mithilfe des Repository-Dispatch-Webhooks auftritt.
GitHub führt die CI-Tests aus und stellt die Ergebnisse jedes Tests in der Pullanforderung bereit, sodass Sie sehen können, ob die Änderung in Ihrem Zweig einen Fehler verursacht. Sobald alle CI-Tests in einem Workflow bestanden wurden, können die per Push übermittelten Änderungen von einem Teammitglied geprüft oder zusammengeführt werden. Wenn ein Test nicht bestanden wird, liegt die Ursache eventuell in einer Ihrer Änderungen.
Wenn Sie CI in Ihrem Repository einrichten, analysiert GitHub den Code in Ihrem Repository und empfiehlt CI-Workflows basierend auf der Sprache und dem Framework in Ihrem Repository. Wenn Sie beispielsweise Node.jsverwenden, schlägt GitHub eine Vorlagendatei vor, die Ihre Node.js-Pakete installiert und Ihre Tests ausführt. Sie können die von GitHubvorgeschlagene CI-Workflowvorlage verwenden, die vorgeschlagene Vorlage anpassen oder eine eigene benutzerdefinierte Workflowdatei zum Ausführen der CI-Tests erstellen.
Sie können nicht nur ci-Workflows für Ihr Projekt einrichten, sondern auch GitHub Actions verwenden, um Workflows über den gesamten Softwareentwicklungslebenszyklus hinweg zu erstellen. Sie können Ihr Projekt beispielsweise mithilfe von Aktionen bereitstellen, packen oder veröffentlichen. Weitere Informationen finden Sie unter "über GitHub Actions".
Eine Definition von gebräuchliche Begriffe finden Sie unter "Kernkonzepte für GitHub Actions".
Unterstützte Sprachen
GitHub bietet CI-Workflowvorlagen für eine Vielzahl von Sprachen und Frameworks.
Browse the complete list of CI workflow templates offered by GitHub in the actions/starter-workflows repository.
Benachrichtigungen für Workflow-Läufe
Wenn Sie E-Mail- oder Webbenachrichtigungen für GitHub Actions aktivieren, erhalten Sie eine Benachrichtigung, wenn ein von Ihnen ausgelöster Workflow abgeschlossen ist. Die Benachrichtigung enthält den Status der Workflow-Ausführung (einschließlich erfolgreicher, fehlgeschlagener, neutraler und abgebrochener Ausführungen). Sie können auch auswählen, ob Sie nur dann eine Benachrichtigung erhalten möchten, wenn eine Workflow-Ausführung fehlgeschlagen ist.
Sie können den Status von Workflow-Ausführungen auch auf der Registerkarte „Actions“ (Aktionen) eines Repositorys einsehen. Weitere Informationen findest Du unter „Eine Workflow-Ausführung verwalten."
Status-Badges für Workflow-Läufe
A status badge shows whether a workflow is currently failing or passing. Ein häufiger Ort zum Hinzufügen eines Status-Badge ist in der README.md-Datei Deines Repository, aber Du kannst ihn zu jeder beliebigen Webseite hinzufügen. By default, badges display the status of your default branch. Du kannst auch den Status einer Workflow-Ausführung für einen bestimmten Branch oder ein bestimmtes Ereignis anzeigen, indem Du die Abfrageparameter branch (Branch) und event (Ereignis) in der URL verwendest.
Weitere Informationen finden Sie unter „Einen Workflow konfigurieren“.
