Argumente für ein CI System

Neulich wurde ich zum wiederholten Male nach einer kurzen und möglichst Managementtauglichen Zusammenfassung gefragt. Es wurden Argumente für die Einführung eines Deployment Systems (bzw. Continuous Integration, hier Bamboo von Atlassian) gesucht, denen sich auch leitende Personen nicht entziehen können.

Software Metriken und Nightly Builds sind schön und gut, aber diese lassen meist keinen direkten ROI erkennen.

Daher die Liste nun einmalig als Copy&Paste Vorlage für weitere Anfragen:

Versionssicherheit

Einzig Daten die auch commitet wurden und somit beabsichtigt im Release gelandet sind, gehen online
Rollback Möglichkeit

Beim Feststellen eines Fehlers muss man nur den Rollback Button drücken
Prozessoptimierung Richtung QA

Die QA kann Ihre Umgebungen jederzeit selber installieren, wodurch aus Sicht der Entwicklung nur noch das Zuweisen von Tickets an die QA notwendig ist. Hierdurch werden Wartezeiten und manuelle Prozesse eliminiert; nach der Installation kann sofort mit dem Testen bzw. der Abnahme begonnen werden
Installation per Knopfdruck

Manuelle Fehlerquellen werden minimiert, da der CI Server (Bamboo, Jenkins …) über die Versionsverwaltung (Git, SVN …) die zu installierenden Dateien lädt und so ein „Release Paket“ über den Klick „eines“ Buttons live gestellt werden kann
Nachvollziehbarkeit

Es ist über die Historie des CI Servers sichergestellt, dass man jedes Release, welches online ging. mit allen den darin enthaltenen Änderungen einsehen kann (interessant für Wirtschaftsprüfer)
Benachrichtigungen

Nach einem (erfolgreichem) Deployment wird eine konfigurierbare Empfängergruppe informiert
Qualitätssicherung

Vor einem Release werden alle Unit Tests ausgeführt und so sichergestellt, das keine fehlerhaften Sourcen (korrekte Tests vorausgesetzt) online gehen können

Achtung: Diese Liste ist nicht vollständig und wurde mit Blick auf eine max. 5 minütige Diskussion hin optimiert.