Software­projekt FINAS Quick-Check ÖD Teil 3: CI/CD-Pipeline & Cloud

In diesem Teil möchte ich beschreiben, wie der Softwareentwicklungsprozess in unserem Projekt technisch abgelaufen ist und welche Werkzeuge wir genutzt haben, damit alles rund läuft und wir uns auf das Wesentliche konzentrieren konnten. Zudem werde ich auf das Thema Cloud eingehen, denn die Cloud wird immer wichtiger, wenn es darum geht, Anwendungen schnell und unkompliziert zu deployen.

Aufgrund des explorativen Ansatzes in unserem Projekt FINAS Quick-Check ÖD war es besonders wichtig, dass wir nach dem Prinzip von CI/CD entwickeln. Was bedeutet das? Mit dem Aufkommen agiler Methoden in der IT laufen Entwicklung, Qualitätssicherung (QS) und Bereitstellung der Software nicht mehr als einzelne Stufen nacheinander ab, sondern werden immer mehr miteinander verzahnt. Die Ergebnisse der Entwicklung sollen möglichst schnell zur Verfügung stehen. In den letzten Jahren hat sich daher zunehmend die Praxis von Continuous Integration (CI) und Continuous Delivery bzw. Continuous Deployment (CD) etabliert. Das heißt, dass wir Änderungen in kurzen Zyklen in die Software integrieren können (CI) und sie zeitnah an die Anwender ausliefern, damit sie für einen schnellen Test und für fachliche Rückläufe genutzt werden können. In agilen Projekten werden die Änderungen, also z.B. die Ergebnisse eines Sprints, auch oft kurzfristig in einer Live-Produktivumgebung bereitgestellt (CD).

Unser Ziel war es vor allem, dass Entwicklung, Test und Deployment so weit wie möglich automatisiert werden und zugleich dafür gesorgt ist, dass die Qualität der ausgebrachten Software stimmt. Um dies zu erreichen, kam unsere „Development Pipeline“ zum Einsatz.

Das, was alles zusammenhält: die Development Pipeline

• Zum einen natürlich die Entwicklungsumgebung, die jeder Softwareentwickler und jede Softwareentwicklerin auf dem eigenen Rechner hat, um den Sourcecode zu programmieren, die Anwendung lokal zu starten sowie zu testen.
• Zum anderen eine Source-Verwaltung, in der der gemeinsam entwickelte Code ablegt wird.
• Um gegenseitig unseren Code nach dem Vier-Augen-Prinzip überprüfen zu können, haben wir ein Code-Review-Tool genutzt.
• Ein Build-Server, um die Software zentral zu bauen und die Unit-Tests auszuführen.
• Außerdem ein QS-Tool zur automatischen Kontrolle der Codequalität/Testabdeckung.
• Zu guter Letzt eine Deployment-Umgebung, in der die Software deployt wird. 

In der folgenden Grafik habe ich die Development Pipeline, wie wir sie in unserem Projekt FINAS Quick-Check ÖD verwendet haben, einmal grob skizziert:

Am Anfang steht – wie sollte es anders sein 😉 – immer ein Entwickler oder eine Entwicklerin, um den Code vom lokalen Rechner auszuchecken, Änderungen an der Software zu programmieren und dann in die gemeinsame Source-Verwaltung einzubringen (→pushen). Als Source-Verwaltung haben wir das weit verbreitete Git mit dem vorgelagerten Code-Review-Tool Gerrit verwendet. Damit Änderungen final in der Source-Verwaltung „verewigt“ werden konnten, wurde zunächst ein Prozess in Gang gesetzt, in dessen Verlauf der Code zwei wichtige Hürden nehmen musste.

Erstens, und das geschieht ganz automatisch mit dem Push, wird die Pipeline gestartet, in deren Verlauf 

• die Software auf dem Build-Server ausgecheckt, gebaut und die Unit-Tests ausgeführt, 
• die Codequalität und die Testabdeckung von einem Code-QS-Tool geprüft (wir verwenden SonarQube),
• und die Software für das Deployment als Docker-Image gebaut und dann in der Azure-Cloud als Container in einem Kubernetes-Cluster deployt werden.

Wenn auch nur an einer Stelle dieses Prozesses etwas schiefgeht, z.B. ein Unit-Test fehlschlägt oder die Testabdeckung nicht das gewünschte Maß erreicht, wird der Prozess abgebrochen und der Entwickler bzw. die Entwicklerin benachrichtigt (→Build ist rot). Wird der Prozess bis zum Deployment erfolgreich durchlaufen, sind die Änderungen schon testbar.

Die zweite Hürde, die der eingecheckte Code überwinden musste, war die Kontrolle durch ein weiteres Teammitglied. Dieses prüft die Codeänderungen nach dem Vier-Augenprinzip und bringt ggfs. noch Änderungswünsche ein. Für eine solche Kontrolle stellt das Tool Gerrit eine komfortable Benutzeroberfläche zur Verfügung. Erst wenn die Pipeline erfolgreich durchgelaufen ist und der Reviewer zu den Codeänderungen sein OK gegeben hat, werden die Änderungen in die Source-Verwaltung dauerhaft übernommen (→submitted).

Das Ergebnis

Am Schluss hatten wir also einen manuell und automatisch qualitäts­gesicherten Code sowie einen testbaren Stand der Anwendung in der Cloud mit dem neuen Feature. Und das Ganze so von Tools unterstützt, dass alle Beteiligten sich auf das Wesentliche konzentrieren konnten: Die korrekte Umsetzung der Vorgaben und die Qualität des Codes.

Im Zusammenhang mit dem Deployment habe ich eben einige Begriffe verwendet, auf die ich im folgenden Absatz noch etwas näher eingehen möchte.

Cloud, Container und Cluster

Mein Rechenzentrum im Internet

Wie wir gesehen haben, ist die Endstation der Pipeline das Deployment in der Cloud. Was aber verbirgt sich genau dahinter? „DIE CLOUD“, das war für mich anfangs immer ein etwas schwammiger Begriff. Einerseits ein Ablageort von Dateien, auf die man dann von überall und von allen Geräten zugreifen konnte, andererseits gab es da dann auch noch das hochkomplex erscheinende Konzept des Cloud-Computing. Nachdem ich mich ein bisschen damit beschäftigt hatte, bin ich für mich persönlich zu dem Schluss gekommen, dass die Cloud einfach mein „Rechenzentrum im Internet“ ist. Also eigentlich alles wie bisher, nur dass ich mich nicht mehr um Dinge wie Serverräume, Server, Kühlung, Wartung, Softwareupdate, Netzwerke etc. kümmern muss, da die Cloud mir das alles zur Verfügung stellt.

Theoretisch ist alles viel einfacher und flexibler geworden: Mit ein paar Klicks bestelle ich mir die nötigen Server­kapazitäten und mit ein paar weiteren Klicks bestelle ich sie auch wieder ab. In der Praxis ist es dann aber meist doch nicht immer ganz so einfach. Die Möglichkeiten sind quasi unendlich groß und als Nutzer der Cloud muss man sich oft durch einen Dschungel von Konfigurationsmöglichkeiten kämpfen.

Wir hatten uns dazu entschieden, den FINAS Quick-Check ÖD selbst zu betreiben und auch als Software as a Service bereitzustellen. Unsere Kunden erhalten jeweils einen (individualisierten) Link, über den sich die Anwendung aufrufen und z. B. in den eigenen Internetauftritt einbinden lässt. Der Grund für ein Deployment in der Cloud war, dass es uns auf der einen Seite die Möglichkeit gibt, die Anwendung ohne größere Aufwände direkt in Produktion zu bringen. Auf der anderen Seite können wir durch den Betrieb in der Cloud einfach und schnell auf einen Anstieg der Nutzerzahlen reagieren und die Anwendung entsprechend skalieren.

Inzwischen gibt es viele große Cloudanbieter, z. B.  Amazon Web Services, Google Cloud Platform, IBM Cloud etc. In unserem Projekt haben wir die Azure-Cloud von Microsoft verwendet, da sie viele Möglichkeiten und eine gute Kostenkontrolle bietet. Die Lernkurve empfand ich persönlich für den Einstieg aber auch als sehr steil.

Container

Unser FINAS Quick-Check ÖD läuft in einem Container – also einem "Behälter“ für die Anwendung. Hierbei handelt es sich um eine gekapselte Laufzeit­umgebung für die Applikation. Man kann es sich wie eine Miniaturversion einer virtuellen Maschine vorstellen, die ihr eigenes kleines Betriebssystem dabei hat, mit allem was die Anwendung braucht – und auch nur das. Dadurch ist sie von dem Betriebssystem, auf dem der Container läuft, unabhängig. 

Um eine Anwendung in der Cloud zu deployen, wird sie in einem Container „verpackt“ und daraus ein Image erstellt, sprich eine Bauanleitung für den Container, die in einer Registry abrufbar ist. In unserem Projekt haben wir „Docker“ verwendet, die am weitesten verbreitete Containertechnologie.

Cluster

In der Cloud läuft unsere Anwendung in einem sogenannten Cluster. Das ist eigentlich nichts anderes  als ein Stück Software, mit dem man „containerisierte" Anwendungen (s.o.) laufen lassen kann und das einem einige grundlegende wünschenswerte Eigenschaften einer Webanwendung ermöglicht. Stichworte sind hier:

• Skalierbar: Der Cluster sorgt dafür, dass bei einem erhöhten Bedarf automatisch zusätzliche zusätzliche Container gestartet werden.
• Verteilt: Die Anwendung kann z.B. auf verschiedene geografische Zonen verteilt werden. Dies sorgt u.a. für Ausfallsicherheit.
• Überwachbar: Der Cluster ermöglicht das Überwachen von Ressourcenverbrauch, Zugriffen und sowie das Logging.

Den Kontext von Cloud, Container und Cluster habe ich hier noch einmal in einer Grafik dargestellt:

Rückblickend kann ich sagen: Wir haben im Rahmen des Projekts alles geschafft, was wir uns vorgenommen hatten. Wir haben die Ergebnisse, die zuvor in der Foundation Phase erarbeitet wurden, umgesetzt und die Anwendung in verhältnismäßig kurzer Zeit auf die Beine gestellt. Dabei haben wir mit modernen Frameworks gearbeitet. Dies hat uns die Arbeit enorm erleichtert und es ermöglicht, eine Anwendung zu erstellen, die nicht morgen bereits wieder überholt ist. Mit unserer Development Pipeline haben wir den Entwicklungsprozess schlank und gleichzeitig effizient gestaltet – immer mit Blick auf die Qualität sowie die Anforderungen von CI/CD.

Mir persönlich hat das Projekt extrem viel Spaß gemacht. Jeder im Team war an allen Entscheidungen beteiligt und hat sich sowohl fachlich als auch technisch voll eingebracht, damit wir unser gemeinsames Ziel erreichen. Außerdem war es nochmals eine gute Gelegenheit, mich mit den Aspekten Betrieb bzw. Hosting einer Anwendung zu beschäftigen und mein Wissen über Cloud-Technologien zu vertiefen und anzuwenden.

So, jetzt aber genug geredet. Wer neugierig auf unseren FINAS Quick-Check ÖD geworden ist und ihn selbst einmal ausprobieren möchte – die Standardversion der Anwendung und weitere Informationen gibt es hier.