Wer heutzutage im Team Software-Projekte realisiert, kommt an Continuous Integration nicht mehr vorbei. Die Vorteile des Prozesses überwiegen den anfänglichen Einrichtungsaufwand in einem solchen Maß, dass es – bis auf sehr kleine Projekte – keinen rationalen Grund gibt, nicht mit Continuous Integration zu arbeiten. In diesem Blog möchte ich Continuous Integration und unsere persönliche Realisierung in unseren Software-Projekten vorstellen.
Was ist Continuous Integration?
Continuous Integration (CI), oder zu deutsch kontinuierliche Integration, meint das regelmäßige (am besten mehrmals täglich) Zusammenfügen von Änderungen im Software-Projekt. Ziel ist es, Komplikationen in Software-Projekten frühzeitig zu erkennen. Dies verhindert einen riesigen Berg an Problemen, welcher nach monatelanger simultaner Implementierung innerhalb eines Projekts beim finalen Zusammenfügen entstehen könnte. Teil des Zusammenfügens sind Aktionen welche neben dem Übersetzen und Linken auch die Softwarequalität durch automatisierte Tests überprüfen. Das Ganze wird auf einem Build-Server realisiert. Dies garantiert die Unabhängigkeit von lokalen Modifizierungen einzelner Entwickler. Außerdem erhält man einen Bezugs-Build, welcher dann im weiteren Verlauf an den Kunden ausgeliefert werden kann. Die IEC 62304 Norm der Medizinproduktesoftware erfordert ein solches Konfigurationsmanagement. Für uns ist Continuous Integration daher ein Muss, aber auch in anderen Branchen kann man es als Stand der Technik bezeichnen. Um Genanntes zu realisieren ist eine Versionsverwaltung unvermeidlich. Im nächsten Schritt möchte ich das von uns dafür verwendete Tool vorstellen.
GitLab CI
Beispiel des visuellen Feedbacks der CI Pipeline von GitLab
GitLab ist erst einmal eine Open-Source Versionsverwaltung. Es erweitert seine Funktionalität unter anderem um ein Wiki und ein Ticketsystem. Durch die Verwendung von GitLab wird uns viel Pflege und Validierung abgenommen, sodass es für uns ein attraktives Tool für die Software-Entwicklung ist. Des Weiteren integriert es GitLab CI, was Continuous Integration realisiert. GitLab CI wird über die Datei .gitlab-ci.yml im Repository konfiguriert. Eine ausführliche Anleitung bietet GitLab CI/CD. Grundsätzlich wird bei jedem Push auf einem Build-Server eine Pipeline zum Übersetzen, Linken und Testen gestartet. Die Entwickler können die genaue Ausgabe nachverfolgen und werden bei einem Fehler informiert. In jedem Schritt der Pipeline werden die erzeugten Artefakte automatisch archiviert und zum Download bereitgestellt. Somit können zu jedem bestimmten Software-Stand die konkreten Artefakte zugeordnet werden. Des Weiteren erhält man ein visuelles Feedback in Form von grünen Häkchen oder roten Kreuzen, was motiviert Code für eine fehlerfreie Pipeline zu generieren.
Unsere Pipeline
Unsere CI-Pipeline
Unsere persönliche CI-Pipeline besteht aus zwei Schritten. Zuerst wird das Projekt gebaut, dann folgt der Test-Schritt. Es ist jedoch jedem frei gestellt seine Pipeline selbst zu gestalten und zu erweitern. Vor jedem Job innerhalb der Pipeline wird wieder der Originalzustand hergestellt, um auf einer sauberen Code-Basis zu arbeiten. Dies wird mit einem Check-out auf die aktuelle Version realisiert.
Check-out der sauberen Code-Basis
Ich gebe im Folgenden einen kurzen Überblick über unsere Pipeline, deren Sinn und die verwendeten Tools.
Clean Build
Dieser Schritt ist der wichtigste Teil der Pipeline und sollte als Erstes durchgeführt werden. Dies ist insofern wichtig, da ein erfolgreiches Bauen Grundvoraussetzung für weitere Tests ist. Um Reproduzierbarkeit und Nachvollziehbarkeit zu garantieren ist ein Clean Build auf einem Build-Server unabdingbar. Bei jeder Codeänderung wird automatisiert auf einem Server mit fixen Einstellungen das Projekt gebaut. Dies schafft eine verlässliche Code-Version, welche später dem Kunden bereitgestellt werden kann.
Statische Codeanalyse
Noch bevor man die Software mit Unittests überprüft ist es sinnvoll eine statische Codeanalyse durchzuführen. Hierbei wird der Quellcode unter anderem auf Speicherlecks, Pufferüberläufe, falsche Casts oder „Out-of-Bound“-Zugriffe untersucht. Ein sehr bekanntes Tool, welches auch wir verwenden, ist PC-lint. Dabei handelt es sich um kommerzielle Software, welche eine herausragende Funktionalität hat. Sie bietet unter anderem ausgiebiges Feedback.
Der Kostenpunkt gilt bei der statischen Codeanalyse nicht als Ausrede. So gibt es jede Menge kostenlose Software. Wir verwenden hier Cppcheck. Die Funktionalität ist deutlich begrenzter, aber es ist durchaus sinnvoll eine kostenlose Codeanalyse zu verwenden, da auch diese schon deutlich Arbeitsaufwand und Nerven sparen kann und weiterhin die Codequalität steigert.
Doxygen
Ein weiteres Tool in unserer CI-Pipeline ist Doxygen. Dabei handelt es sich um ein kostenloses Software-Dokumentationswerkzeug. Der eigentliche Verwendungszweck des Tools sieht das Erstellen einer übersichtlichen Dokumentation des Sourcecodes vor. Für Projekte verwenden wir die Dokumentationsfunktion von Doxygen nicht, sondern betrachten lediglich die Warnungen des Tools. Somit kann sichergestellt werden, dass jede Funktion, Variable, etc. ausdrücklich kommentiert und erläutert wurde und somit ein guter Code-Review und allgemein eine gute Verständlichkeit des Sourcecodes gewährleistet ist.
Ceedling
Als letzten Schritt unserer CI-Pipeline haben wir ein Unittest-Tool integriert. Ceedling ist ein in Ruby geschriebenes Unittest Framework welches Rake, Unity und CMock verwendet. Es ist Open-Source und speziell für die Programmiersprache C gedacht. Des Weiteren ermöglicht das Tool Test-Driven Development (TDD). Aus diesen Gründen haben wir uns entschieden Ceedling für unsere Unittests zu verwenden. Es lassen sich sehr einfach Tests erstellen und diese automatisch ausführen. Diese testen den Sourcecode auf korrekte Funktionalität und können somit auch Fehler, welche erst durch spätere zusätzliche Implementierungen oder Code Änderungen entstehen, aufdecken. Das Feedback des Tools entspricht unseren Anforderungen. So erhält man konkrete Rückmeldung darüber, wo und was im Sourcecode fehlerhaft war und kann dies dann im Folgenden beheben. Dies setzt natürlich das Schreiben von sinnvollen Unittests voraus. Bei Ceedling handelt es sich um ein praktisches Unittest-Tool, welches diverse hilfreiche Plugins integriert.
In einem älteren Artikel haben wir bereits über Testabdeckung gesprochen. Grundsätzlich kann man sagen, dass nicht nur die prozentuale Testabdeckung entscheidend ist, sondern vor allem die Nachvollziehbarkeit darüber, welche Codezeilen getestet wurden und welche nicht. Ceedling integriert das Tool gcov. Mit diesem ist es unfassbar einfach, sich eine solche Testabdeckung ausrechnen und anzeigen zu lassen. Man erhält neben dem Prozentsatz der Abdeckung visuelles Feedback darüber, welche Zeilen einer Source-Datei ausgeführt wurden. Dies ist sehr hilfreich, um einen schnellen Überblick über fehlende Unittests für eine Source-Datei zu bekommen.
Beispiel des visuellen Feedbacks von gcov zur Testabdeckung
Fazit
Zusammenfassend kann man sagen, dass Continuous Integration ein Standard ist, welcher bei größeren Software-Projekten unbedingt Anwendung finden sollte. In der Medizintechnik ist das Konfigurationsmanagement ab der Software-Sicherheitsklasse A vorgeschrieben. CI kann einen Beitrag dazu liefern die Anforderungen der IEC 62304 an das Konfigurationsmanagement zu erfüllen. Die Gestaltung der Pipeline ist natürlich variierbar und man kann seine persönlich bevorzugten Tools verwenden, trotzdem muss das Testkonzept den Anforderungen der Software-Sicherheitsklasse entsprechen. Unsere Wahl zur Realisierung einer CI-Pipeline ist auf GitLab CI gefallen, da GitLab auch andere für uns praktische Tools, wie ein Wiki oder ein Ticketsystem integriert. Es gibt jedoch auch andere gute Tools, um eine CI-Pipeline zu erzeugen.
Gerne können Sie sich an uns wenden, wenn Sie Fragen haben oder Hilfe bei der Einrichtung einer CI-Pipeline benötigen.
