Was ist Continuous Integration

Unter Continuous Integration (CI) versteht man eine kontinuierliche Integration der Code Änderungen an Software Produkten in einem zentralen Source Code Repository mit anschließender oder sogar vorausgehender (Gated Check-in) Verifikation der Integration durch Kompilierung, Code Analyse, Unit, Integration, E2E, Security und Performance Tests. Die anschließende Paketierung stellt die kompilierten und getesteten Applikationsteile als Artefakte für späteres Deployment zur Verfügung.

CI bietet damit eine essenzielle Grundlage für die schnelle Qualitätssicherung der Code-Änderungen in Projekten mit mehreren Entwicklern an. Insbesondere in agilen verteilten Teams mit mehreren Modulen und Schnittstellen stellt diese Methode eine notwendige Stütze für schnelle Erkennung und Reaktion auf Fehler und Probleme mit der Weiterentwicklung von Software-Produkten dar.

Continuous Integration bildet dabei die erste Phase der gesamten Continuous Delivery (CD) Prozesskette, die alle Schritte umfasst, die eine automatisierte Bereitstellung von Geschäftsapplikationen bis in die Produktion zu jedem Zeitpunkt ermöglicht. Diese Fähigkeit wird als „Production-Readiness“ bezeichnet. Continuous Integration ist damit ein zentraler Teil der Arbeitspraktiken moderner agiler Software-Entwicklung, die eine technische Säule für eine effiziente und schnelle Bereitstellung der Software Produkte bzw. neuer Features in agilen Projekten darstellen.

Eine typische Continuous Integration Kette besteht aus folgenden Schritten:

Continuous Integration Kette

 

Ziele von Continuous Integration

  • Zeitnahe und häufige Einbettung der neuen Code-Änderungen im zentralen Repository
  • Erhöhung der Code-Ausfallsicherheit und Nachvollziehbarkeit
  • Standardisierte systematische und reproduzierbare Builds und Tests auf definierter Infrastruktur
  • Beschleunigung der Feedback Schleife (Build Fehler, Software Bugs)
  • Beschleunigung der Release Cycles und Reduktion der Kosten
  • Erhöhung der Software Qualität
  • Erhöhung der Kundenzufriedenheit

 

Best Practices

  • Einheitliche Branching Strategie
  • Check-ins mind. 1x pro Tag durch jeden Entwickler
  • Build Fehler Benachrichtigungen einrichten und hochpriorisiert fixen
  • Build Trigger nach jedem Commit
  • Minimierung der CI-Pipe Laufzeiten
    • max. 8 h für nightly CI Builds
    • max. 30 min für On-Commit CI Builds
  • Transparente Zugänglichkeit der Build Ergebnisse für jedes Team Mitglied

 

Auswirkungen auf Qualitätssicherung in agilen Projekten

  • QS primär nur durch vollautomatisierte und tägliche Tests
  • Testreports und Teststatus in CI Tool
  • Keine risikobasierte Tests, keine Testpläne, keine Test Cycles, keine Test Closure Reports
  • Ablösung von Test Management Tools
  • Keine explizite Test Manager mehr notwendig (aber Koordination trotzdem erforderlich)

 

Verwandte Begriffe