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.