Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


Im Weekly bekommt Moritz diese Woche zum ersten Mal einen lauffähigen Durchstich zu sehen. Gleichzeitig erfährt er aber von den Schwierigkeiten des Teams, die Umgebung stabil zu betreiben. Aufgrund ihrer Arbeitsteilung in den beiden Gruppen entwickeln sie ihre Komponenten weitestgehend unabhängig voneinander, was sie grundsätzlich gut finden. Die Schnittstellen zwischen den Komponenten sind im Wiki ausreichend gut beschrieben. Sie stimmen sich auch regelmäßig im Teamwork ab, wenn es dort Änderungsbedarf gibt. Trotzdem gab es in den letzten Tagen immer wieder Probleme.

Das Teamwork wollen sie heute nutzen, um mit Moritz über mögliche Lösungen für diese Probleme zu sprechen. Ein Problem hat das Team schon identifiziert: Ihnen fehlt der Überblick über die in der Umgebung installierten Komponenten. Sie wollen in Zukunft eine Art Release- oder Change-Log schreiben.

Moritz fragt vorsichtig nach, was sie sich von ihrer Maßnahme versprechen. Im Gespräch meint er zu erkennen, was ihre Absicht ist. Er befürchtet aber, dass ein Change-Log nicht die erhoffte Lösung ist. Um seine Bedenken für die Studenten nachvollziehbar zu machen, erzählt er von einem Vorgehen, das er in einem anderen Projekt erlebt hat. In diesem Projekt wird jede Komponente einzeln installiert. Ziel ist ein störungsfreien Betrieb. “Rolling updates” wurde das Konzept dazu genannt.

In dem Projekt gibt es ein Stofftier für jede von mehreren Teams gemeinsam genutzte Umgebung. Die Testumgebung wurde beispielsweise durch einen Teddy repräsentiert. Ein Team “besitzt” die Testumgebung, indem sie symbolisch den Teddy an sich nimmt. Damit haben die DevOps dieses Teams offiziell die Verantwortung für die Testumgebung – und natürlich auch für den Teddy. Ihre erste Tätigkeit ist die Überprüfung der Funktionsfähigkeit des IT-Systems noch vor ihrer ersten Änderung. Dann erst installieren sie ihre neuen Komponenten. Dann überprüfen sie erneut die Funktionsfähigkeit des IT-Systems. Neben der obligatorischen Analyse von Log-Dateien sind ihre wichtigsten Hilfsmittel Integrations- und Systemtests in einer automatisch ausgeführten CI-Pipeline.

Ein Schnittstellentest überprüft eine interne technische Schnittstelle zwischen zwei Komponenten eines IT-Systems. Jede Komponente für sich ist eine Blackbox. Ein Schnittstellentest überprüft aber nur einen kleinen Ausschnitt des IT-Systems. Der Fokus liegt dabei auf den Übergängen von Komponenten mit unterschiedlichen Verantwortlichen.

Weiterlesen auf cardsplus.info

Ein Systemtest überprüft das IT-System an den öffentlichen Schnittstellen. Das ganze System ist eine Blackbox. Der Systemtest verhält sich wie ein Daten lieferndes externes Partnersystem und überprüft die ausgehenden Daten wie ein abnehmendes externes Partnersystem.

Weiterlesen auf cardsplus.info

Schlägt ein Test fehl, wird die Testumgebung so schnell wie möglich zurück in den Zustand vor der Installation versetzt. Allerdings muss erneut die CI-Pipeline zeigen, dass die wiederhergestellte Testumgebung lauffähig ist. Das Team mit dem Teddy ist erst entlastet und kann das Stofftier abgeben, wenn die Umgebung wieder “grün” ist.

Wurden jedoch alle Tests fehlerfrei abgeschlossen, dann ist die installierte Komponente offiziell integriert. Das Team gibt den Teddy und damit die Testumgebung wieder frei und das nächste Team kann übernehmen.

Zur Dokumentation der Zusammenstellung von Komponenten wird eine “baseline” der Testumgebung erstellt, in der jede installierte Komponente mindestens mit Version und Konfiguration aufgelistet ist. Ausschließlich auf Basis so einer “baseline” wird eine Installation in der Produktionsumgebung gemacht.

Und das ist der Punkt, an dem Moritz seinen Lösungsvorschlag macht. « Jedes IT-System bildet ein mehr oder weniger komplexes Netzwerk von Komponenten. Jede Komponente hat eine bestimmte Version und Konfiguration. Nur ganz bestimmte Zusammenstellungen von Komponenten bilden ein lauffähiges IT-System in einer Umgebung. Diese Kombinationen müssen wir kennen. Ich nenne das einen Release-Kandidaten. »

Richard fragt nach: « Ok. Wir nennen es Change-Log. Du nennst es Release-Kandidat. Für mich ist das sehr ähnlich. Gibt es dafür einen Baustein in CARDS+? »

« Einen Baustein gibt es nicht. », antwortet Moritz.

« Eine Umgebungsübersicht ist also ein Arbeitsdokument. Alles klar. Dann legen wir die Seite im Teambereich an. », antwortet Richard.

Moritz widerspricht: « Da hab ich mich wohl schlecht ausgedrückt. Ich will keine Seite in Confluence. Jede Umgebung zeigt selbst, was sie kann. Jede installierte Komponente wird angezeigt, mindestens mit der Version und aktueller Konfiguration. Zusätzlich kann eine API-Dokumentation oder ein PDF mit Betriebsanweisungen online verfügbar sein. »

In einem IT-System ist jede Komponente ein Knoten in einem mehr oder weniger komplexen Netzwerk. Eine Umgebungsübersicht ist ein zentraler Anlaufpunkt für die Betriebsorganisation, aber auch für Entwickler und Tester. Sie beinhaltet Informationen über die Version jeder Komponente, welche Komponente wie oft als Instanz existiert, wie viel Speicher sie verwendet oder wie ihr aktueller Zustand ist. Abhängig von der gewählten Architektur zeigt so eine Übersicht noch viele weitere Merkmale.

Weiterlesen auf cardsplus.info

Moritz erzählt von der Lösung aus dem Kundenprojekt. In diesem Projekt wird Consul als Verzeichnisdienst und Consul-Templates für die Konfiguration verwendet. Ein Python-Skript sammelt Daten aus dem Consul-Cluster ein und erzeugt eine einfache baumartige Übersicht der Komponenten mit Version und Konfiguration. Das Python-Skript zusammen mit einem Webserver wird als Docker-Container in jeder Umgebung installiert. « Mehr kann ich euch dazu leider nicht sagen. »

Die Unsicherheit bei den Studenten ist spürbar. « Sollen wir jetzt auch Consul verwenden? », fragt Tim.

« Nein, so meine ich das nicht. Ich will damit sagen, dass wir mit einfachen Mitteln versuchen sollten, so eine dynamische Übersicht zu realisieren. », schlägt Moritz vor. « Zum Beispiel mit Gitlab oder mit der neuen Version von Rancher. »

Für beide Werkzeuge gibt es Kollegen im Unternehmen, die sich sehr gut auskennen. Gitlab gehört bereits seit Langem zur Infrastruktur des Unternehmens und ist das IT-Service für Code-Repositories. Es besteht daher für Moritz ein starkes strategisches Interesse, wenn sich auf Basis von Gitlab Git, Gitlab CI, Gitlab on Kubernetes und Gitlab Auto DevOps eine Lösung für eine dynamische Übersicht über die Komponenten einer Umgebung bauen ließe. Auf der anderen Seite verspricht Rancher in Version 2 ebenfalls Container-Management und -Orchestrierung vom Feinsten auf Basis von Kubernetes.

Moritz und das Team beschließen, einen Versuch zu wagen. Ziel ist eine Prüfung der Machbarkeit einer dynamischen Umgebungsübersicht mit den Mitteln, die Gitlab oder Rancher standardmäßig anbieten.

Moritz legt gleich eine Story für einen Proof-Of-Concept in Trello an. Aufgrund der Unsicherheit im Team legt er eine Timebox fest. Moritz unterstreicht, dass er ihnen zwar maximalen Spielraum bei der Lösung einräumt, aber nicht beliebig viel Zeit. Das Team darf bei diesem Versuch auch scheitern.

Sie unterhalten sich noch eine ganze Weile über die Anforderungen an so eine dynamisch generierte Liste von Komponenten einer Umgebung und wie ihre Realisierung aussehen könnte. Sie sprechen auch über Komponenten der Infrastruktur, die natürlich auch in dieser Liste aufscheinen müssen.

Zuletzt macht Moritz noch ein nicht mehr ganz so ernsthaftes Angebot: « Wenn ihr für eure Lösung ein Stofftier braucht, dann besorge ich eines. »

« Auf jeden Fall brauchen wir das Stofftier. », witzelt Tim. « Mindestens als Maskottchen. »

« Alles klar Tim. Dann bekommst du den Auftrag, im Team abzustimmen, welches Stofftier es sein soll. Und gebt dem Tierchen einen Namen. », antwortet Moritz.

Zuletzt veröffentlichte Beiträge: