Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht 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 unter 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 du z. B. Node.js verwendest, schlägt GitHub Enterprise Server einen Workflow zum Einstieg vor, der deine Node.js-Pakete installiert und deine Tests ausführt. Du kannst den von GitHub Enterprise Server vorgeschlagenen CI-Workflow zum Einstieg übernehmen, den vorgeschlagenen Workflow zum Einstieg anpassen oder eine benutzerdefinierte Workflow-Datei für die 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 findest du unter Informationen zu GitHub Actions.
Eine Definition allgemeiner Begriffe findest du unter Grundlegendes zu GitHub Actions.
Workflows zum Einstieg
GitHub Enterprise Server umfasst CI-Workflows zum Einstieg für verschiedene Sprachen und Frameworks.
Durchsuche die vollständige Liste der von GitHub angebotenen CI-Startworkflows im actions/starter-workflows-Repository auf Ihre GitHub Enterprise Server-Instance.