Um den Begriff „CI“ in einen größeren Zusammenhang zu stellen, sollte man wissen, dass „CI“ die Abkürzung für „Continuous Integration“ (kontinuierliche Integration) ist. Die Definition von CI lautet wie folgt: Bei Continuous Integration (CI) geht es darum, die Codeänderungen aller Projektmitwirkenden regelmäßig in ein zentrales Repository zu übernehmen. Da an einem Projekt in der Regel mehrere Entwickler*innen arbeiten, ist es wichtig, die einzelnen Teile an einem zentralen Ort zusammenzuführen. Idealerweise läuft dieser Vorgang automatisiert und mehrmals täglich ab. Das Ziel von Continuous Integration besteht darin, ein verlässliches Verfahren für die Kompilierung und Bereitstellung von Software sicherzustellen, indem Zusammenarbeit, Automatisierung und kurze Feedback-Zyklen gefördert werden.
Der praktische Einsatz von Continuous Integration beginnt damit, dass Codeänderungen regelmäßig in ein Quellcode- bzw. Versionsverwaltungssystem hochgeladen werden, damit alle Mitwirkenden auf dieselbe Grundlage aufbauen. Jeder Commit löst die Erstellung eines Builds und die Durchführung einer automatisierten Testreihe aus, um das Codeverhalten zu überprüfen und sicherzustellen, dass die Änderung nicht zu Fehlern führt. Continuous Integration hat zwar für sich genommen schon Vorteile, gleichzeitig ist sie aber auch der erste Schritt zur Implementierung einer CI/CD-Pipeline.
Durch eine klare CI-Definition und die Implementierung dieser Methode in ihren Entwicklungsprozess können Teams ihre Arbeitsabläufe optimieren und die Qualität ihrer Software verbessern.
Continuous Integration erfordert die folgenden Grundkomponenten:
Damit alle Mitwirkenden auf dieselbe Basis aufbauen können, müssen alle dasselbe Repository nutzen und ihre Änderungen häufig miteinander teilen. Eine gute Faustregel ist, dass jeder Mitwirkende seine Änderungen mindestens einmal am Tag per Commit in Main/Trunk einpflegen soll.
Nachdem wir eine Änderung vorgenommen haben, besteht der nächste Schritt darin, einen Build zu erstellen und eine Reihe automatisierter Tests durchzuführen, um das Verhalten des Codes zu überprüfen. Die Automatisierung dieses Prozesses ist ein wesentlicher Bestandteil von Continuous Integration. Ein manueller Build- und/oder Testprozess wäre zeitaufwändig und fehleranfällig und würde dem Ziel, Änderungen täglich zu integrieren, zuwiderlaufen. Die genauen Buildtools und Testframeworks, die dabei zum Einsatz kommen, hängen von der verwendeten Sprache ab.
Nach der erstmaligen Erstellung der Skripte und Tests muss der Prozess weiter gepflegt werden. Dies bedeutet, für jede neue Funktion automatisierte Tests hinzuzufügen, Fehler zu beheben und die Performance des Prozesses zu überwachen.
Ein CI-Server, der sich um die Überwachung Ihres Repositorys kümmert, Builds auslöst, automatisierte Tests ausführt und Ergebnisse zusammenführt, hilft Ihnen dabei, all diese Einzelteile zusammenzufügen, beim Schreiben individueller Automatisierungsskripte Zeit zu sparen und auf ergänzende Informationen wie Code-Coverage-Werte und den Buildverlauf zuzugreifen.
Diese Tools und Prozesse sind zwar für die Implementierung von Continuous Integration wichtig, aber um optimale Ergebnisse zu erzielen, müssen Sie auch Ihre Mitarbeiter*innen für diese Methode begeistern. Das gesamte Entwicklungsteam muss seine Prozesse so anpassen, dass regelmäßige Commits in den Main-Branch erfolgen, für jedes neue Feature automatisierte Tests erstellt werden und die Korrektur des Builds allgemeine Priorität genießt, wenn etwas schiefgegangen ist. Priorisierung, Entwurf und Wartung automatisierter Tests erfordern eine Zusammenarbeit mit der Qualitätssicherung, und zur Bereitstellung von Systemen, auf denen Builds und Tests ausgeführt werden können, ist eine Kooperation mit dem Infrastrukturteam gefragt – beides trägt zum Abbau von organisationsinternen Trennmauern bei.
Obwohl die Vorteile der Continuous Integration nicht auf das Entwicklungsteam beschränkt sind, sondern das gesamte Unternehmen umfassen, heißt das nicht, dass sie überall mit offenen Armen empfangen wird.
Für viele Softwarehäuser stellt DevOps eine enorme Veränderung in Bezug auf bestehende Arbeitsweisen und Prozesse dar. Damit die teamübergreifende Koordination gelingt und eine Kultur der Zusammenarbeit entsteht, ist eine gute Kommunikation erforderlich.
Wenn Sie bereits agile Methoden einsetzen, ist die Umstellung in der Regel etwas einfacher, da bereits ein Bewusstsein für das Konzept der selbstorganisierenden Teams und für die Bedeutung von Feedback als Steuerinstanz der Entwicklung besteht.
Wo dies nicht der Fall ist, kann es beim Überzeugen Ihrer Kolleginnen und Kollegen hilfreich sein, sich die Größenordnung der Veränderung bewusst zu machen, auf die Menschen zuzugehen, klein anzufangen und Stück für Stück die Vorteile zu demonstrieren.
Aber es gibt auch praktische Herausforderungen, die bei der Continuous Integration gelöst werden müssen. Wenn Sie an einer großen, monolithischen Anwendung arbeiten, können die Build-Zeiten lang sein, und wenn Testumgebungen knapp sind, ist es schwierig, Testläufe zu parallelisieren.
Ein guter Überblick über Ihren Continuous-Integration-Workflows und der Zugriff auf Performance-Kennzahlen zur Ermittlung von Engpässen können dazu beitragen, Kosten und Nutzen von Investitionen in Architekturänderungen, Infrastrukturerweiterungen und automatisierte Tests zu quantifizieren.
Durch Continuous Integration können Entwicklungsteams den Veröffentlichungszyklus ihrer Software beschleunigen, ohne bei der Qualität Kompromisse einzugehen. Das Hauptziel von Continuous Integration besteht darin, potenzielle Risiken, die während des Deployments auftreten können, zu minimieren und die Feedback-Schleife zu verkürzen.
Zentrale Vorteile der Continuous Integration sind:
Durch Continuous Integration, Delivery und Deployment können Unternehmen ihre Kosten reduzieren und den Software-Lieferzyklus erheblich verkürzen. Wenn sie richtig eingesetzt werden, tragen diese Systeme wesentlich dazu bei, die Prozesse im Zusammenhang mit dem Kompilieren, Testen und Bereitstellen von Software effizienter zu gestalten. Bei der Verwendung von CI/CD sollten unter anderem folgende Best Practices berücksichtigt werden:
Es ist unmöglich, eine stabile, zuverlässige CI/CD-Pipeline ohne die entsprechenden CI/CD-Tools aufzubauen. Diese helfen Ihnen bei der Koordination der unterschiedlichen Teile der Pipeline, vom Auslösen des Integrationsvorgangs über die Ausführung automatisierter Tests bis hin zur Bereitstellung des Codes für den Produktionseinsatz. Ganz gleich, ob Sie ein integriertes CI/CD-Tool wie TeamCity verwenden, das alle Phasen des CI/CD-Prozesses unterstützt, oder die verschiedenen Bereiche mit unterschiedlichen Systemen abdecken – die gewählten Tools sollten in jedem Fall den gesamten Tech-Stack Ihres Teams unterstützen. Ebenfalls wichtig ist es, dass sich diese Tools in die anderen Softwaresysteme integrieren lassen, die Sie bei der Arbeit verwenden, und sie müssen anpassungsfähig und flexibel genug sein, um Workflows beliebiger Komplexität zu unterstützen.
Anstatt die Vorteile von CI und CD gegeneinander abzuwägen, ist es sinnvoller, sich zu überlegen, wie diese unterschiedlichen Teile des Entwicklungsprozesses zusammenwirken können, um Sie dabei zu unterstützen, Ihrer Benutzergemeinde fehlerfreie Softwareanwendungen bereitzustellen.
Bei Continuous Integration geht es darum, Codeänderungen in einem Hauptbranch zusammenzuführen. Continuous Delivery baut auf den Grundlagen auf, die in der Continuous-Integration-Phase durch Test- und Build-Automatisierung gelegt wurden. Continuous Deployment ist die letzte Phase im CI/CD-Prozess. Dabei wird die neue Softwareversion – vorausgesetzt, sie erfüllt alle Anforderungen – an die Benutzergemeinde ausgeliefert.
Continuous Integration beschleunigt den Entwicklungsprozess und verbessert gleichzeitig die Codequalität. Durch die Automatisierung der einzelnen Schritte können Sie effizienter arbeiten und sich darauf konzentrieren, Mehrwert für Ihre Benutzergemeinde zu schaffen. Continuous Integration ist jedoch nur der Beginn der CI/CD-Pipeline. Die nächste Stufe, Continuous Delivery, wendet die DevOps-Grundsätze auf den nächsten Teil des Releaseprozesses an.