Was ist ein CI-Server?

At the start of any CI/CD pipeline is an integration with your version or source control system.

Bei einer einfachen Implementierung wird Ihr CI/CD-Server so konfiguriert, dass er auf Commits im Master-Branch reagiert und bei jeder Änderung einen Pipeline-Durchlauf auslöst.

Dadurch wird zwar sichergestellt, dass jeder Commit verifiziert und getestet wird, es kann aber immer noch leicht passieren, dass der Commit einer Person zu einem Buildfehler führt, den Prozess zum Stillstand bringt und dadurch die Überprüfung weiterer Änderungen verhindert, bis der Fehler entweder zurückgenommen oder behoben wurde.

Wenn Sie Ihren CI-Server so konfigurieren, dass ein Commit erst möglich ist, wenn ein Build der Änderungen erstellt und getestet wurde, vermeiden Sie solche Probleme und bieten Ihrem Entwicklungsteam außerdem eine zusätzliche Feedback-Schleife.

Wichtig ist, dass der Buildserver Unterstützungs- und Aufsichtsinstanz gleichzeitig ist: Er führt den Buildvorgang und die Tests auf einem Remote-System durch und meldet die Ergebnisse zurück, macht diesen Prozess jedoch auch zur Bedingung für einen Commit im Master- oder einem Feature-Branch.

Ein weiterer sinnvoller Schritt ist die Integration zwischen dem CI-Server und Ihrem Code-Review-Tool, sodass jede Änderung ein Code-Review bestehen muss, bevor sie als Commit übernommen wird – allerdings erst, nachdem ein Build erfolgreich erstellt und getestet wurde.

Diese zusätzlichen Schichten von Geschäftslogik zu Beginn des Prozesses tragen dazu bei, dass Ihr Codebestand sauber bleibt und stets releasefähig ist. Gleichzeitig werden Unterbrechungen und Verzögerungen in der Pipeline minimiert.

Wenn Ihre CI/CD-Pipeline die Build- und Testphase erreicht, ist Ihr CI-Server die Schaltzentrale hinter diesen Abläufen: Er koordiniert Aufgaben und weist den Build-Agents anhand verschiedener Kriterien Jobs zu.

Die eigentliche Arbeit beim Buildvorgang und bei der Testausführung wird allerdings – gemäß den Anweisungen des CI-Servers – von Ihren Build-Agents übernommen.

Es empfiehlt sich, zumindest in Produktionsumgebungen den Build-Server von den Build-Agents zu trennen, auf denen Builds und Tests ausgeführt werden, um Ressourcenkonflikte und Leistungsprobleme zu vermeiden.

Wenn Sie auf Ihrem CI-Server die Logik für eine Pipeline-Phase konfigurieren, können Sie eine Reihe von Details und Regeln festlegen. Vielleicht sollen manche Tests nur bei Commits im Master-Branch ausgeführt werden, nicht aber bei einem Pre-Commit-Build in einem Entwicklungs-Branch; oder vielleicht möchten Sie bestimmen können, wie viele Builds gleichzeitig auf eine Testdatenbank zugreifen können.

Durch die gleichzeitige Ausführung bestimmter Aufgaben mithilfe von Build-Agents können Sie die Effizienz Ihrer Pipeline erhöhen. Dies ist hilfreich, wenn Sie Tests auf verschiedenen Betriebssystemen ausführen müssen oder wenn Sie mit einer riesigen Codebasis mit Hunderttausenden Tests arbeiten und die Parallelisierung die einzige praktische Option darstellt. In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.

Wenn der Build-Server eine Integration mit Cloud-Infrastrukturen wie AWS bietet, können Sie elastische, skalierbare Ressourcen nutzen, um Ihre Builds und Tests auszuführen. Unterstützung für containerisierte Build-Agents und die Integration mit Kubernetes können bei erheblichem Infrastrukturbedarf hilfreich sein, um Build-Ressourcen – egal ob lokal oder Cloud-basiert – effizient zu verwalten.

Ein wichtiger Aspekt Ihrer Geschäftslogik besteht darin, für jede Phase der CI/CD-Pipeline zu definieren, was als Fehler gelten soll.

Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.

Neben offensichtlichen Fehlern – etwa wenn der Buildvorgang einen Fehlercode zurückgibt oder wenn ein Test nicht ausgeführt werden kann – können Sie anhand der vom Build-Server gesammelten Daten weitere Fehlertypen definieren.

Beispiele hierfür wären die Abnahme der Test-Coverage-Rate im Vergleich zum Vorgängerbuild (dies zeigt an, dass keine Tests für die neuesten Codeänderungen hinzugefügt wurden) oder eine höhere Anzahl von ignorierten Tests im Vergleich zum letzten erfolgreichen Build.

Diese Zahlen sind Warnsignale, dass sich die Codequalität verschlechtert haben könnte. Indem Sie diese Fälle als Fehler definieren und nicht allen Benutzer*innen das Ignorieren dieser Fehler erlauben, können Sie positives Verhalten fördern.

Auch wenn der Name „CI-Server“ eine Beschränkung auf Continuous Integration andeutet, unterstützen die meisten CI-Server auch Continuous Delivery und Continuous Deployment.

Nachdem in der Continuous-Integration-Phase die Build-Artefakte erstellt und eine erste Reihe von Tests ausgeführt wurden, besteht der nächste Schritt darin, diese Artefakte für weitere Testreihen in QA-Umgebungen bereitzustellen. Im Anschluss daran können die Stakeholder den Build in Staging-Umgebungen ausprobieren, und wenn alles gut aussieht, folgt die Veröffentlichung.

As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. Sie können dann entscheiden, ob Ihre Deployment-Skripte entsprechend dem Ergebnis der vorherigen Phase automatisch ausgelöst werden sollen.

Schnelles Feedback aus jeder Phase ist ein Schlüsselaspekt einer CI/CD-Pipeline.

Ein Build-Server kann Informationen zu Job-Warteschlangen, Echtzeitberichte zu Builds und Tests bereits während der Ausführung sowie Statusinformationen zu abgeschlossenen Build-Schritten bereitstellen.

Durch die Aktivierung von Benachrichtigungen können Sie sicherstellen, dass Ihr Team bei eventuellen Problemen sofort informiert wird. Eine Integration mit Bug-Tracking-Tools wiederum bietet Detailinformationen zu den Korrekturen, die in einem Commit enthalten sind, und ermöglicht eine schnelle Analyse von Fehlerursachen. Historische Daten können nützliche Erkenntnisse zur Verbesserung Ihrer Pipeline sowie zur Definition von Bedingungen in der Pipelinelogik ermöglichen.

Ein Continuous-Integration-Server spielt eine tragende Rolle bei der Umsetzung Ihrer CI/CD-Pipeline, der Koordination und Auslösung der verschiedenen Prozessschritte sowie der Erfassung und Bereitstellung von Daten aus den einzelnen Phasen. Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.