Continuous Integration
Continuous Integration (übersetzt als permanente oder fortlaufende Integration) beschreibt einen Prozess in der Softwareentwicklung, der zum Ziel hat, die vorhandenen bzw. neu entstehenden Komponenten einer Anwendung zusammenzufügen. Dadurch soll die Qualität der Software gesteigert werden.
Bei der Continuous Integration (CI) geht es nicht darum, das gesamte System neu zu bauen, sondern durch automatisierte Tests und Softwaremetriken Aussagen über die Softwarequalität machen zu können [1].
Allgemeine Informationen zum Thema
Je größer Softwareprojekte werden, desto komplexer und schwieriger werden sie in der Handhabung. Da in der Regel zahlreiche Entwickler am Projekt beteiligt sind, entstehen früher oder später Integrationsfehler, die sich teils nur schwer beheben lassen. Continuous Integration soll hier Abhilfe leisten.
Grundsätzlich geht es bei Continuous Integration darum, dem Ansatz entgegenzuwirken, Software in sehr großen Zeitabständen und erst kurz vor der Auslieferung zu erstellen. Stattdessen wird sie in kleinen Zyklen wiederholt erstellt und ständig getestet. Durch diese Praxis soll verhindert werden, dass Fehler erst am Tag des Release erkannt werden. Damit Continuous Integration realisiert werden kann, muss der Quellcode mit Hilfe eines Versionskontrollsystems verwaltet werden, die Entwickler wiederum müssen ihrerseits ihre Arbeitsstände permanent in dieses System zurückspielen. Die Software wird nach jedem Commit oder bei zeitintensiven Builds in regelmäßigen, kurzen Abständen gebaut.
Danach werden Codeanalysen und Tests durchgeführt, um zum Schluss die Software zum Beispiel mit einem Stage-System bereitzustellen. Die beteiligten Entwickler und unter Umständen andere Beteiligte werden im Anschluss daran über den Build-Vorgang in Kenntnis gesetzt und können sich die Analysen, Logs und Ergebnisse ansehen. Auf diese Weise erhalten die Entwickler die Mitteilung über fehlerhafte Commits nicht über Kollegen, sondern mittels permanenter Rückmeldungen durch den Continuous Integration Server. Den Projektleitern und Kunden stehen, je nach Bedarf, stets aktuelle Informationen über den Entwicklungsstand oder ein aktuelles Testsystem zur Verfügung[2].
Aufbau eines Continuous Integration Systems
Ein CI-System besteht aus mehr Komponenten als nur dem CI-Server, wie in der unten abgebildeten Grafik zu erkennen ist. Ausgegangen wird von dem Projekt, mit dem Continuous Integration arbeiten soll, und von dem entsprechenden Quellcode. Das Entwicklerteam übergibt die Änderungen, die es durchführt, am Quellcode mittels Commit an das VCS. Vorher wird dem Server bekannt gemacht, wo innerhalb des VCS sich das Projekt befindet. Dazu wird in aller Regel eine VCS-spezifische URL verwendet. Beinahe wie ein Entwickler erzeugt nun der CI-Server eine lokale Arbeitskopie des Projektes.
Ab sofort richtet der CI-Server in regelmäßigen Zeitabständen Anfragen an das VCS, ob sich im betroffenen Projekt seit dem letzten Mal Änderungen ergeben haben. Falls ja, wird im CI-Server ein neuer sogenannter CI-Build angestoßen. Der erste Schritt innerhalb eines solchen CI-Builds ist grundsätzlich, dass der CI-Server eine lokale Arbeitskopie vom VCS durch ein Update aktualisiert. Anschließend wird im nächsten Schritt das Projekt mit diesen aktuellen Dateien "gebaut", das bedeutet üblicherweise Kompilieren und Ausführen der automatisierten Tests.
Testausführung und Kompilierung werden nicht durch den CI-Server, sondern durch ein Build-Tool durchgeführt wie Make oder Maven. Voraussetzung dafür ist die im Vorfeld durch das Entwicklerteam durchgeführte Automatisierung des Bauvorgangs und die Verwendung von Build-Tool spezifischen Dateien, also etwa Mavens POMS oder Makefiles.
Abhängig davon, wie der Aufruf des Build-Tools ausgeht, wird durch den CI-Server der gesamte CI-Build abschließend klassifiziert. Dabei folgt er folgendem Schema:
1. Erfolgreich: Weder beim Kompilieren noch während der automatisierten Tests haben sich Fehler ergeben.
2. Warnung: Zwar war sowohl das automatisierte Testen als auch das Kompilieren erfolgreich. Dennoch traten kleine Fehler auf, etwa fehlgeschlagene Tests oder auch Warnungen seitens des Compilers.
3. Fehler: Das CI-Build wird als gescheitert betrachtet, weil es zahlreiche oder kritische Fehler gab. Dabei kann es sich um das Überschreiten einer gewissen Anzahl von fehlgeschlagenen Tests handeln oder auch um einen Abbruch des Compilers.
Der CI-Server kann durch den Zugriff auf das VCS ermitteln, wer aus dem Entwicklungsteam die Veränderungen bezüglich des letzten CI-Builds ausgelöst hat. Die Entwickler wiederum werden abschließend über das Build-Ergebnis über E-Mail oder andere Wege informiert. So erfahren sie zeitnah, ob ihre Veränderungen zu Problemen oder Fehlern geführt haben.
Bedeutung für das Development
Continuous Integration ist im Laufe der Zeit zu einem zentralen Instrument der Softwareentwicklung geworden. Der Weisheit letzter Schluss ist Continuous Integration jedoch nicht, denn die Entwicklungen gehen weiter, andere Ideen und Konzepte betreten immer wieder die Spielfläche. Zu ihnen zählen beispielsweise Continuous-Delivery, aber auch Lösungen mit Virtualisierungen und Clouds oder Application Lifecycle Management(ALM).
Dennoch lässt sich festhalten, dass Continuous Integration in der Praxis oft die richtige Wahl ist und dass dieses System ein angesehenes Mittel für die Optimierung in der Softwareentwicklung ist. Systeme wie die außerdem genannten, spielen aber ebenso eine Rolle in der Softwareentwicklung, und es ist davon auszugehen, dass sich auf diesem Gebiet noch viel tun wird[3].
Einzelnachweise
- ↑ Kontinuierliche Integration de.wikipedia.org. Abgerufen am 19.03.2018
- ↑ Einführung in die Continuous Integration mit Jenkins entwickler.de. Abgerufen am 19.03.2018
- ↑ Continuous Integration in Zeiten agiler Programmierung heise.de. Abgerufen am 19.03.2018