Continuous Integration oder warum wir nachts gut schlafen können

Druck Ikon schwarz

Continuous Integration in der Produktentwicklung oder Warum wir nachts ruhig schlafen können

Kleines Porträt Darius Felski

Veröffentlicht in Magazin (Technologie)

Darius Felski

Eine alltägliche Situation bei encoway: Ein Kollege aus dem Vertrieb führt einen potenziellen Kunden durch die Büros der Entwicklungsabteilung. Er erklärt die Organisationsstruktur und die Prozesse, verliert ein paar Worte über das Kanban-Board auf dem Fernseher an der Wand und zeigt die coolen Gadgets auf dem Schreibtisch in der Ecke. Und er erklärt dabei, dass die hochmotivierten Jungs und Mädels gerade an der nächsten Version des Produkts arbeiten, welches in dem sich anbahnenden, gemeinsamen Projekt zum Einsatz kommen soll. Daraufhin stellt der Kunde natürlich gerne die Frage: „Kann ich es sehen?“. Die Antwort darauf lautet bei encoway seit geraumer Zeit: „Aber klar! Ich zeige Ihnen den aktuellen Stand.“

Continuous Integration ist der Grund dafür, dass diese Frage bei encoway nicht mehr mit einem charmanten „Ich zeige Ihnen einen Showcase der stabilen vor-vorletzten Version, da ist aber noch nicht alles drin…“ beantwortet werden muss. Oder dass bei Anfrage erst eine lauffähige Version umständlich zusammenkopiert werden muss. Continuous Integration sichert (neben weiteren Methoden der Agilen Softwareentwicklung) unsere Softwarequalität und gewährleistet die Bereitstellung einer lauffähigen Version zu jeder Zeit.

Die Softwarequalität steht im Fokus

Es ist unser Anspruch in der Produktentwicklung, jederzeit eine lauffähige und potenziell auslieferbare Software bereitzustellen. Dies hilft nicht nur bei unangekündigten Besuchen, sondern dient, ganz im Sinne agiler Projekte, der Realisierung möglichst kurzer Demo- und Releasezyklen.

In der Produktentwicklung geht es um eine nachhaltige Softwareentwicklung. Die entstehenden Produkte werden über viele Jahre bei diversen Kunden eingesetzt und müssen möglichst gut auch für zukünftige Anforderungen gewappnet sein. Daher haben wir bereits bei der Definition der Anforderungen zu Beginn des Entwicklungsprozesses die Softwarequalität im Blick. Durch zu Beginn festgelegte Akzeptanzkriterien grenzen wir den Umfang einzelner Aufgaben klar voneinander ab. Diese Kriterien helfen sowohl den Entwicklern bei der Umsetzung als auch den Testern bei der Definition der Integrationstests.

Eine hohe Code-Qualität ist für langlebige Produkte unerlässlich. Konventionen und Regeln sorgen bei uns für lesbaren und wartbaren Quellcode. Die „Richtigkeit“ unseres Codes stellen wir mittels testgetriebener Entwicklung sicher. „Richtigkeit“ steht dabei für „die Dinge richtig, also fehlerfrei tun“. Durch die konsequente Orientierung an den zu Beginn definierten Akzeptanzkriterien entstehen auf die essentiellen Bestandteile fokussierte Lösungen. Wir vermeiden damit die Entwicklung von Lösungen „auf Vorrat“, also solcher Lösungen, die nur vielleicht mal gebraucht werden könnten. 

„Bei mir geht’s!“ - „Bei mir auch!“ 

Die Sensibilisierung für die Qualität der Software allein reicht nicht aus. Wir wollen stets sehen, wie es um sie bestellt ist. In Zeiten agiler Softwareentwicklung ist Continuous Integration ein bewährtes Mittel um eine ständige Releasefähigkeit zu gewährleisten. Und die Anforderungen, die dabei an den Softwareentwicklungsprozess gestellt werden, erhöhen wiederum die Transparenz der Softwarequalität.

Um kurze Releasezyklen zu erreichen, achten wir auf kleine und für jeden Beteiligten verständlich formulierte Arbeitspakete. So integrieren wir häufig Code in den Hauptentwicklungszweig. Damit sorgen wir für eine stetige Weiterentwicklung der Software mit kurzen Reaktionszeiten und unter Einhaltung unserer Qualitätskriterien.

Jede Komponente der Software ist und bleibt in jeder Umgebung „baubar“. Dafür sorgt die gemeinsame Codebasis, verwaltet in einem Versionskontrollsystem, und der einheitliche Build-Prozess. Das gilt für jede Entwicklermaschine sowie für den Continuous Integration Server.
Zum Build-Prozess gehört bei uns selbstverständlich auch die Ausführung der automatisierten Tests. Zum einen in Form von Unit-Tests, die bei testgetriebener Entwicklung stets eine sehr hohe Code-Abdeckung aufweisen. Zum anderen führen wir Integrationstests aus, die zuvor aus den Akzeptanzkriterien abgeleitet wurden. Bei der Kombination werden nicht nur die Komponenten der Software isoliert, sondern auch in Kombination miteinander, als Abbildung von fachlich orientierten Anwendungsfällen getestet.  Der einheitliche Build-Prozess macht etwaige Test-Fehler reproduzierbar, was die Suche nach der Ursache erleichtert.

Während die Software „gebaut“ wird, werden diverse Metriken und Reports erstellt, um direkt nach jedem Entwicklungsschritt die aktuellen Zahlen wie Testabdeckung oder Code-Komplexität und deren Trends sehen zu können. Regelverletzungen werden in Form von „technischer Schuld“ transparent gemacht. Mittels Quality-Gates definieren wir die produktbezogenen Qualitätskriterien und gehen auch soweit, dass durch eine einzige Regelverletzung der Build-Prozess abgebrochen wird.

Alle beschriebenen Maßnahmen im Sinne einer Continuous Integration sorgen dafür, dass die Software stets stabil läuft. Jederzeit. Und ein potenzieller Kunde kann wenige Augenblicke nach seiner Frage den aktuellen, im vollen Umfang getesteten Stand der Software ausprobieren. Das ist sehr beruhigend – für uns Softwareentwickler und auch für den Vertrieb.