DevOps – geänderte Anforderungen führen zu neuen Bugs?!

In dem vorherigem Artikel ging es um ein immer wieder kehrendes Problem aus der Praxis – die Anforderung des Kunden hat sich geändert. Die Vorgehensweise zur Qualitätssicherung ist in diesem Artikel näher beschrieben.

Hier geht es um das Thema Automatisierung von alltäglichen, meist bekannten Prozessen:

  • geänderte Anforderung – neue Fehler?
  • Integration neuer Funktionen (Continous Integration)
  • automatische Builds mit anschließenden Tests

Fehler treten immer wieder auf, können aber durch folgende Schritte bereits frühzeitig festgestellt und behoben werden:

  1. Änderung am Code durchführen
    => geänderte Anforderung wird umgesetzt
  2. Alle Tests laufen lassen, um sicherzustellen, dass die bestehende Funktionalität weiterhin in Ordnung ist
    => Alles Tests sind weiterhin grün
  3. Sicherstellen, dass sich der geänderte Code auch weiterhin integrieren lässt und auch keine abhängigen Projekte betroffen sind
    => Es müssen alle Projekte, die die gemeinsame Codebasis verwenden, geprüft werden

Was ist bei der Integration neuer Funktionalität zu beachten? Auch hier gibt es immer wieder kehrende Schritte:

  1. Abholen der letzten stabilen Version der Software aus der Versionskontrolle
  2. Lokales kompilieren der neuen Codebasis
  3. Alle Tests lokal ausführen
  4. Alle auftretenden Fehler müssen behoben werden
  5. Sind alle Tests grün?
    => Die neue Codebasis kann eingecheckt werden

Durch den Check-In Vorgang lassen sich weitere Prozesse anstoßen, die weitestgehend automatisiert auf einem oder mehreren Build-Servern ablaufen können. Die meisten Build-Tools führen diese Workflow-Schritte bereits ohne größere Konfiguration aus.
Im folgenden ein Ausschnitt eines möglichen Build-Prozesses:

  1. Hole die letzte Version mit allen Projekten
  2. Kompiliere alle betroffenen Projekte
  3. Generiere eine eindeutige Build-Nummer
  4. Stelle das Kompilat auf einem (Test-) Server bereit
  5. Starte alle vorhandenen Tests
  6. Im Fehlerfall: Informiere den notwendigen Personenkreis, dass Fehler aufgetreten sind.
    => Prozess wird hier beendet
  7. Kein Fehler: Stelle das Ergebnis auf einer Staging-Umgebung bereit
  8. Konfiguriere alle weiteren Komponenten wie Datenbanken o.ä.
  9. Stelle die Software bereit, z.B. SQL-, Deploy-Skripte, etc.

Meine Empfehlung:

Aus eigener Erfahrung kann ich nur jedem Team – egal ob Entwicklung oder Betrieb – ans Herz legen, automatisierte Builds mit anschließenden Tests einzuführen. Jedes Teammitglieder sollte in der Lage sein, innerhalb weniger Stunden eine neue, stabile Softwareversion zu erzeugen. Dazu gehört aber nicht nur die Erstellung eines Setups oder der Skripte zur Bereitstellung der Software sondern auch die automatische Integration in die bestehende Software (Continous Integration). Bereits bei einer kleinen Änderung muss automatisch sichergestellt sein, dass der Rest der Software davon nicht beeinträchtigt wird. Eine ständige Integration von neuen Funktionen in eine Versionskontrolle gehört ebenso zu den Grundvoraussetzungen wie ein gesundes Maß an Automatisierung.