Note
Auf GitHub gehostete Runner werden aktuell nicht auf GitHub Enterprise Server unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
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 Codecommit an das Repository kannst du 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. Du kannst Aktualisierungen lokal erstellen und testen, bevor du den Code per Push an ein Repository sendest, oder auch einen CI-Server nutzen, der neue Codecommits in einem Repository überprüft.
Informationen zur fortlaufenden Integration mit GitHub Actions
CI mit GitHub Actions bietet Workflows an, die den Code in deinem Repository erstellen und deine Tests ausführen können. Workflows können auf GitHub-gehosteten VMs ausgeführt werden, oder auf Computern, die du selbst hostest. Weitere Informationen findest du unter Verwenden von auf GitHub gehosteten Runnern und Informationen zu selbstgehosteten Runnern.
Du kannnst den CI-Workflow so konfigurieren, dass er bei einem GitHub-Ereignis (z. B. wenn neuer Code per Push in das Repository eingebracht wird), nach einem festen Zeitplan oder bei einem externen Ereignis anhand des Sende-Webhooks des Repositorys ausgeführt wird.
GitHub Enterprise Server führt die CI-Tests durch und liefert die Ergebnisse der einzelnen Tests im Pull Request, sodass du feststellen kannst, ob die Änderung im Branch einen Fehler einbringt. 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 deiner Änderungen.
Wenn du die CI im Repository einrichtest, analysiert GitHub Enterprise Server den Code im Repository und empfiehlt CI-Workflows anhand der Sprache und des Frameworks im Repository. Wenn Sie z. B. Node.js verwenden, schlägt GitHub Enterprise Server eine Workflowvorlage vor, die die Node.js-Pakete installiert und die Tests ausführt. Sie können die von GitHub Enterprise Server vorgeschlagene CI-Workflowvorlage verwenden, die vorgeschlagene Workflowvorlage anpassen oder eine benutzerdefinierte Workflowdatei zur Ausführung der CI-Tests erstellen.
Mit GitHub Actions kannst du nicht nur CI-Workflows für dein Projekt einrichten, sondern auch Workflows für den gesamten Lebenszyklus der Softwareentwicklung. Du kannst dein Projekt beispielsweise mithilfe von Aktionen bereitstellen, paketieren oder freigeben. Weitere Informationen finden Sie unter Schreiben von Workflows.
Eine Definition allgemeiner Begriffe findest du unter Grundlegendes zu GitHub Actions.
Workflowvorlagen
GitHub Enterprise Server umfasst CI-Workflowvorlagen für verschiedene Sprachen und Frameworks.
Durchsuchen Sie die vollständige Liste der von GitHub angebotenen CI-Workflowvorlagen im actions/starter-workflows-Repository in GitHub.com.