October 9, 2020

Continuous Integration bei replikativ

Ich bin ja schon immer ein großer Fan von Automatisierung und habe deshalb oft eher als sogenannter DevOps (entschuldigt den Ausdruck) gearbeitet. Vom Deployment über Monitoring und Continuous Integration (CI) und Delivery habe ich schon viel Erfahrung gesammelt. Der Bereich CI ist etwas Besonderes, weil die Ansprüche immer Andere sind.

Es gibt die Monolithen, die schwerfällig getestet, gebaut und abgespeichert werden. Es gibt unterschiedlichste Testverfahren von Unitttests über Integrationtests bis Browsertests. Und vor Allem der Releaseprozess ist immer etwas sehr maßgeschneidertes. In manchen Unternehmen gibt es feste Releasezyklen, da darf ein neuer Release nur zu bestimmten Zeitpunkten stattfinden und es gibt die sich agil nennenden Unternehmen, in denen ständig veröffentlicht wird. Manchmal wird viel mit libraries, also Softwarebibliotheken gearbeitet, was auch andere Ansprüche stellt.

Beim open-source Projekt replikativ bin ich nun seit ein paar Monaten involviert und habe mich auch gleich bereit erklärt, den CI- und Releaseprozess zu überarbeiten. Hier ist das Besondere, dass es mehrere Bibliotheken gibt, die auch alleinstehend funktionieren und auch genutzt werden, aber auch eine Datenbank (Datahike), die ein Endprodukt darstellt. Die Entwicklung ist also in mehreren Komponenten unter Umständen von einander abhängig.

CircleCI ist im Clojure Umfeld recht beliebt, weil bei CircleCI auch Clojure eingesetzt wird und daher die Unterstützung von Clojure schon immer gut ist. In der neuesten Version von CircleCI kann man jetzt sogenannte Orbs bauen und veröffentlichen, mit denen der Prozess zentral definiert werden kann und dann bei den einzelnen Projekten modular eingesetzt werden kann. Der Gedanke ist gut, allerdings ist das noch nicht so weit gediehen, dass man workflows zentral definieren kann. Das heisst, wenn ich jedem Projekt standardmäßig einen Integrationstest einstellen will, muss ich trotzdem jedes Projekt ändern. Trotzdem ist bisher und auch weiterhin CircleCI für replikativ das CI-Tool der Wahl.

Die replikativ Bibliotheken und auch Datahike werden gerade wieder fit für die Nutzung im Browser gemacht. Dazu werden die CI-Pipelines mit Browsertests versehen und das Buildtool umgestellt. Bisher wurde Leiningen genutzt, jetzt werden die Clojure CLI Tools genutzt. Daher sieht die Continuous Integration aktuell so aus, dass bei einem Commit Unittests, Integrationtests, Browsertests, ein Build und ein Formatierungstest durchgeführt werden. Bald auch in Datahike selber.

Der Releaseprozess soll einheitlich sein und für jedes Projekt unabhängig durchgeführt werden. Bei Commits auf den development Branch wird ein SNAPSHOT-Release erzeugt und auf Clojars veröffentlicht. Bei Commit auf den master Branch wird ein Release erzeugt und ebenso auf Clojars veröffentlicht. Es soll verhindert werden, dass ein Release einer Bibliothek ein davon abhängiges Projekt bricht. Das Hauptprojekt, auf dem das Augenmerk innerhalb von replikativ liegt ist Datahike.

Um einen mit Datahike inkompatiblen Release einer Bibliothek zu verhindern, werden wir den CI-Prozess noch weiter ausbauen. Jede Bibliothek aus replikativ sollte für einen Release einen Integrationstest mit Datahike durchlaufen, damit Probleme frühzeitig erkannt werden. Es soll in Zukunft auch einen Regressionstest in Form eines Benchmarks geben, der als CI-Schritt mitläuft.

Ein Benchmark bringt eigene Herausforderungen mit sich, so ist nicht klar, wann der Test missglückt, es müssen also Quality Gates definiert werden. Außerdem muss die Leistungsfähigkeit der Umgebung normalisiert werden und die Ergebnisse der Tests müssen gespeichert werden. Es gibt also noch ein paar offene Baustellen, was ich in Zukunft auch gerne sehen würde ist die Integration eines Dependency Checkers und evtl. der Anzeige von Code Coverage.

Tags: continuous integration zusammenarbeit cyber