Softwarequalität verbessert durch Continuous Integration und Continous Deployment

Wie kann Qualität und Zuverlässigkeit der Software Komponenten durch unser  Entwicklungsteam gewährleistet werden? Wie werden Softwarefehler frühzeitig erkannt? Das automatisierte Testen und Bereitstellen mit Hilfe von Continuous Integration und Continous Deployment hilft uns dabei und gewährleistet somit Qualität und Zuverlässigkeit unserer Produkte.

Quelle: depositphotos.com

 

Die Anforderungen an eine Software sind dynamisch

Software ist ein Produkt, das durch die Anforderungen eines bestimmten Geschäftsbereichs und dessen Anwender definiert wird. Das bedeutet, Anforderungen an eine Software bestimmen von Anfang an Design, Nutzbarkeit, Architektur und Anwendungslogik eines Produktes. Dabei ist es wichtig zu wissen, dass die zu Beginn des Lebens einer Software definierten Anforderungen immer nur eine konkrete Momentaufnahme darstellen. Anders ausgedrückt, Anforderungen sind niemals statisch, sondern immer dynamisch. Das wird gerade in Zeiten von Digitalisierung und Corona deutlich, wenn Prozesse und Strukturen in den verschiedensten Geschäftsbereichen einer stetigen Veränderung unterliegen.

Wie Continuous Integration und Continous Deployment die Qualität von Software bei M.O.S.S. Computer Grafik System GmbH verbessern

Um diesem schnelllebigen und digitalen Markt gerecht zu werden, setzen wir bei M.O.S.S. zur Entwicklung unserer Software auf Continuous Integration und Continous Deployment. Beides sind Werkzeuge in der modernen Softwareentwicklung, mit deren Hilfe sich wiederkehrende Prozesse beim Entwickeln einer Software automatisieren lassen.
Unter dem Begriff Continuous Integration (CI) [1] wird die fortlaufende Integration von parallelen Änderungen an einer existierenden Software bezeichnet. Dabei werden nach jeder durchgeführten Änderung am Quelltext Build-Prozesse und Unit-Tests in einer festgelegten Umgebung automatisiert ausgeführt. Continuous Deployment (CD) [2] hingegen, bezeichnet die fortlaufende Bereitstellung von aktuellen Änderungen an einer Software. Hierbei wird die im vorherigen Schritt der CI kompilierte und getestete Software automatisiert in einer deterministischen Umgebung installiert, konfiguriert und bereitgestellt.

Frühzeitige Fehlererkennung sichert Qualität der Software

Bei M.O.S.S. setzen wir zu diesem Zweck, die in GitLab integrierte CI/CD-Pipeline-Funktionalität ein. Mit Hilfe dieser einheitlichen Lösung, sind Quelltext und automatisierte CI/CD-Prozesse eng miteinander verbunden und kombinierbar. Dadurch können schon während der Entwicklung unserer Software-Komponenten frühzeitig Fehler erkannt werden und vor der Freigabe behoben werden. Hierzu ein Beispiel anhand unserer neuen Client-Komponente WEGA 10.
Über eine einzelne Datei, die sogenannte .gitlab-ci.yml [3], werden deklarativ die notwendigen Schritte und Skripte für den CI/CD-Prozess definiert. Dazu wird in dieser Datei zuerst basierend auf einem Docker-Image eine deterministische Umgebung für die abzuarbeitenden Schritte und Skripte des CI/CD-Prozesses deklariert.Anschließend werden Stufen, sogenannte Stages, deklariert, welche sequentiell die Ausführungsreihenfolge von einzelnen Schritten innerhalb des CI/CD-Prozesses vorgeben.Auf Basis dieses Gerüsts, können dann Einzelschritte den jeweiligen Stages zugewiesen werden:Innerhalb eines solchen Einzelschritts, können dann Skripte, Paketverwaltungen und andere Werkzeuge zum Kompilieren, Testen und Publizieren der Anwendung aufgerufen werden: Werden dann von einem Entwickler Änderungen am Quelltext nach GitLab zurückgeschrieben, werden automatisch die obigen Einzelschritte sequentiell nach der Reihenfolge der deklarierten Stufen abgearbeitet. Schlägt dann zum Beispiel der Einzelschritt zum Testen von WEGA fehl, bekommen alle beteiligten WEGA 10 Entwickler automatisch eine Benachrichtigung vom System, das die Letzte Quelltextänderung an WEGA 10 zu einem instabilen CI/CD-Prozess geführt hat. Sofortiges Handeln ist angesagt.

Zielgerichtete und schnelle Behebung von Software-Fehlern

In der GitLab-Übersicht aller bisher ausgeführten WEGA 10 CI/CD-Prozesse ist dann zu sehen, dass die zweite Stufe, hier markiert mit einem Kreuz, fehlgeschlagen ist. Anschließen kann der jeweilige Entwickler zügig den Fehler suchen und zielgerichtet beheben. Im Erfolgsfall springt dann der CI/CD-Status in den stabilen Zustand zurückIm letzten Schritt des CI/CD-Prozesses wird automatisch mittels Docker Compose eine aktuelle Version von WEGA 10, die die neu kompilierten und frisch getesteten Funktionen und Bug-Fixes enthält, in einer Docker-Umgebung bereitgestellt. Diese aktuelle Version steht dann für weitere Tests dem Qualitätsmanagement zur Verfügung.

Quellen:

[1] Atlassian, „What is Continuous Integration?,“ [Online]. Available: https://www.atlassian.com/continuous-delivery/continuous-integration. [Zugriff am 03 11 2021].
[2] Atlassian, „What is Continuous Deployment?,“ [Online]. Available: https://www.atlassian.com/continuous-delivery/continuous-deployment. [Zugriff am 03 11 2021].
[3] GitLab Inc., „Keyword reference for the .gitlab-ci.yml file,“ 03 11 2021. [Online]. Available: https://docs.gitlab.com/ee/ci/yaml/.