Der Vortrag beginnt mit einer übersichtlichen Darstellung des zentral verwalteten Continuous-Integration-Systems (CI) der Zürcher Kantonalbank. Dabei wird auf die Hardware- und Software-Ausstattung, aber auch auf die Zusammenhänge und Abhängigkeiten der Einzel-Komponenten, die aus einer Mischung von kommerziellen Werkzeugen und Open-Source-Tools bestehen, eingegangen.
Anschließend werden kurz die Ziele, Techniken und die methodischen Aspekte von Continuous Integration erörtert, um den Sinn und die Zweckhaftigkeit der dann folgenden Fallstudie besser verstehen zu können.
Die Fallstudie verwendet die Softwaresysteme IBM Rational Change (Change- und Problem-Management), IBM Rational Synergy (Software-Konfigurationsmanagement), Jenkins (dedizierter Build-Server), Sonatype Nexus (Artefakt-Repository) und Sonar Qube (Quality-Dashboard). Wir zeigen ausgehend von einem Change Request und den daraus resultierenden Code Changes einen Prozess, der die Teilprozesse
- automatisierter Build
- automatisierte Unit- und GUI- Tests
- automatische Archivierung der Build-Artefakte
- automatisierte Code Style Checks
- Release und Deploy der Build-Artefakte
mit Hilfe eines Build-Servers (Jenkins) und einem modernen Build-Tool, hier Apache Maven, automatisch anstößt und ausführt.
Nach einem erfolgten (virtuellen) Build wird/werden
- die Kommunikation mit den Entwicklern,
- die erzeugten Qualitätsdaten,
- die Zusammenhänge zwischen Feature, Source-Code und Build-Artefakt
- der Deploy in Test- und Produktionsumgebungen (Delivery)
analysiert und ausgewertet. Dabei werden z.B. die Auswirkungen von Aufbau und Verkettung von Jenkins-Jobs auf die Struktur und die Update-Regeln von IBM-Rational-Synergy-Projekten, aber auch auf die Zusammenhänge, die mit dem getrennten Speichern von Source-Code (IBM Rational Synergy) und Produkten (Build-Artefakte) in alternativen Repositories (Sonatye Nexus) auftreten unter Nutzung von Produkt-Staging-Techniken, wie sie in Softwarestabilisierungsphasen üblich sind, diskutiert.
