Continuous Integration (CI) ist ein Prozess, bei dem software während der Entwicklung kontinuierlich kompiliert und getestet wird, während Änderungen an ein Revisionskontrollsystem übermittelt werden. Ziel ist es, Probleme wie Codeänderungen, die den Build stören, fehlerhafte Einheitstests und fehlerhafte Funktionstests so schnell wie möglich nach der Übermittlung einer solchen Änderung zu erkennen. Indem diese Probleme früher erkannt werden, können sie auch schneller behoben werden, was die Auswirkungen auf das gesamte Team verringert. In einer agilen Software Entwicklungsmethodik ist diese Art von unmittelbarem Feedback entscheidend für ein Team, um seine iterativen Ziele zu erreichen.
Das Einrichten einer CI-Umgebung besteht aus mehreren Teilen:
- Dedizierte Baumaschine
- Kontinuierliche Integration software
- Automatisierte und wiederholbare Builds
- Automatisierte Unit- und Funktionstests
CSS verwendet einen kontinuierlichen Integrationsprozess für alle unsere software Entwicklungsarbeiten.
Eine spezielle und eigenständige Produktionsmaschine dient als "Reinraum"-Umgebung für die Herstellung von software Produkten. Diese Maschine ist eine kontrollierte Umgebung, in der neue software und Upgrades nur dann stattfinden, wenn es unser Entwicklungsplan erlaubt. Build-Maschinen werden oft in einer virtualisierten Umgebung eingerichtet, was eine einfache Erweiterung ermöglicht und "zukunftssicher" ist, falls später mehr Kapazität benötigt wird.
Der zweite Teil ist der CI-Server selbst. Es gibt mehrere kommerzielle und open-source CI-Systeme, darunter Jenkins, Microsoft TFS, Atlassian Bamboo, Cruise Control, Cruise Control.NET und viele andere. Der CI-Server ist für die Verwaltung des Arbeitsablaufs Ihres CI-Prozesses verantwortlich. Er kann ausgelöst werden, um ein software Produkt manuell, auf einer Zeitbasis (Nightly Builds) oder auf einer Änderungsbasis zu bauen, indem er Ihr Revisionskontrollsystem kontinuierlich auf Änderungen von Entwicklern hin überwacht. CI-Server führen Ihre Unit-Tests aus und analysieren die Ergebnisse, um den Zustand eines Builds zu ermitteln. Die meisten CI-Server können so konfiguriert werden, dass sie die Build-Artefakte (Binärdateien, Installationen und Symbole) nach einem erfolgreichen Build archivieren.
Eine dritte Komponente sind automatisierte Builds. Ein vollständig automatisierter Build ist sowohl für den CI-Prozess als auch für das Entwicklungsteam von Vorteil. Idealerweise wird das gleiche automatisierte Build-System sowohl von den Entwicklern als auch vom CI-Server verwendet. Ein Entwickler sollte nur einige wenige Voraussetzungen auf seinem Rechner installieren müssen (z. B. Visual Studio). Das Build-Skript sollte sich um das Herunterladen der notwendigen Abhängigkeiten (sowohl intern als auch extern) kümmern, bevor die Erstellung des Quellcodes beginnt.
Der letzte Teil eines CI-Setups (und eine gute Entwicklungspraxis auch ohne CI) sind automatisierte Unit- und Funktionstests. Es ist zwar gut zu wissen, dass eine Reihe von Änderungen am Produkt kompiliert werden kann, aber noch besser ist es zu wissen, dass sie die Funktionalität nicht beeinträchtigen. Noch besser ist es, wenn diese Überprüfung ohne Zutun eines Entwicklers erfolgt, so dass sich die Entwickler auf die Erstellung der Produktfunktionen konzentrieren können.
CI-Prozess in Aktion bei CSS
Unser kontinuierlicher Integrationsprozess setzt ein, sobald ein Entwickler Änderungen in unser Revisionskontrollsystem eincheckt. Wir verwenden derzeit Jenkins als unseren CI-Server. Jenkins hat seine Wurzeln im Java-Bereich, enthält aber inzwischen Hunderte von Plugins zur Erweiterung seiner Funktionalität. Bisher hat es sich bei der Entwicklung unserer .NET-basierten und nativen Code-basierten Produkte sehr bewährt. Wir sind auch große Fans des BruceSchneier-Plug-ins für Jenkins.
Eines der vielen Fakten von Bruce Schneier, die in unserem Build-System erscheinen.
Unser bestehender MSBuild-basierter Build-Prozess machte die Konfiguration von Jenkins einfach. Wir mussten lediglich die Subversion-URL für das Projekt und unser MSBuild-Skript auswählen und den Zielnamen übergeben, der den vollständigen CI-Build darstellt. Wir haben viel Arbeit in unser MSBuild-basiertes Build-System investiert. Unser Ziel ist es, eine einzige MSBuild-Vorlage zu haben, die wir für jedes Produkt wiederverwenden, damit unsere Builds konsistent und zuverlässig sind. Unser MSBuild-Skript führt die folgenden Aufgaben aus:
- Abhängigkeiten herunterladen
- Kompilierung des Codes für das Produkt
- Unit-Test-Projekte werden erstellt und ausgeführt
- Verschleierung wird auf die Build-Ausgaben angewendet
- Authenticode-Signierung der Build-Ausgaben
- Erstellen der Installation
- Authenticode-Signierung der Installation
- Symboldateien, die auf unserem internen Symbolserver veröffentlicht werden
- Archivierung auf unserem internen Dateiserver
Sobald ein Check-in erkannt wird, lädt der CI-Server automatisch die neuesten Produktquellen herunter. Er initiiert einen Quellcode-Build und führt bei Erfolg kontinuierlich unsere Tests aus, erstellt die Installationsprogramme, signiert die Komponenten digital und stellt die Build-Artefakte auf unserem internen Dateiserver bereit. 10-15 Minuten später haben wir einen vollständigen Bericht über den Build, einschließlich der Testergebnisse. Schließlich benachrichtigt uns der CI-Server (entweder über eine Anwendung in der Taskleiste oder per E-Mail), ob der Build erfolgreich war oder nicht.
Kontinuierlicher Integrationsprozess in Aktion.
Schlussfolgerungen
Die Einrichtung eines guten CI-Prozesses ist keine leichte Aufgabe und erfordert mehr als nur einen geringen Arbeitsaufwand, um ihn richtig zu gestalten. Auch wenn dies im Vorfeld mit Kosten verbunden ist, werden sich die CI-Prozesse für die Unternehmen zweifellos auszahlen. Der CI-Prozess wird Fehler bei der Kompilierung des Quellcodes und bei Unit-Tests sofort aufdecken, anstatt sie sich anhäufen zu lassen und die Produktivität des gesamten Teams zu beeinträchtigen. Der Build-Verlauf, einschließlich des Verlaufs der Unit-Test-Ausführung, wird archiviert und ist über das Portal des CI-Servers zugänglich. Ein solider CI-Prozess trägt dazu bei, dass die Entwickler weiterhin Code schreiben, anstatt sich mit sich wiederholenden Aufgaben wie der Ausführung von Unit-Tests oder der manuellen Erstellung des Produkts zu beschäftigen.
Links
- Jenkins CI - https://jenkins-ci.org
- Jenkins-Plugins - https://wiki.jenkins-ci.org/display/JENKINS/Plugins
- Martin Fowler über kontinuierliche Integration - https://martinfowler.com/articles/continuousIntegration.html
- Wikipedia: Kontinuierliche Integration - https://en.wikipedia.org/wiki/Continuous_integration
