CI, CD, DevOps!

theCode unterstützt Teams bei Software Delivery und Kulturwandel

Vorteile von DevOps für Teams

Teams werden durch DevOps befähigt, ihre Produktivität und Effiktivität so zu steigern, dass sie mit weniger Problemen zu häufigeren Releases gelangen. Kürze Problemlösungszeiten und die Zeitersparnis durch die Automatisierung von wiederkehrenden Tasks schaffen Zeit für andere Aufgaben und steigern die Teamzufriedenheit. Für die Produkte verringert sich die Time-to-Market und die Liefertreue kann verbessert werden. Das steigert nicht zuletzt auch die Kundenzufriedenheit.

Unsere DevOps Services

Für uns stehen die individuellen Lösungen im Vordergrund. Die Werkzeuge sollen also bestmöglich zu den Herausforderungen der Teams passen. Wir probieren neben Bewährtem auch gern neue Ansätze aus, sind jedoch nicht Trend-getrieben (muss es immer die Cloud sein?), sondern empfehlen unsere Arbeitsmittel in Abstimmung mit den Teams stets problem- und prozessorientiert. Bei der Auswahl der Tools halten wir uns an die Devise "Keep it simple", um die Architektur ressourcenschonend, einfach und nachhaltig zu gestalten.

Projektbeispiele aus unserer Praxis

Automatisches App-Store Release für 30 iOS und Android Apps

Problemstellung: Das manuelle Releasen von 30 iOS und Android Apps ist zeitaufwendig

Lösung: Release-Prozess automatisieren

Unser Vorgehen:

Die iOS- und Android-App ZWÖLFTER ist in 30 unterschiedlichen Varianten im Appstore und Play Store veröffentlicht worden. Grundlage für den Release-Prozess bilden Fastlane (pilot), Gradle (Gradle-Play-Publisher Plugin) und Jenkins. Screenshots aus den Apps werden mit XCUITest für iOS und Appium für Android erstellt und von einem Bildbearbeitungsprozess (Java) automatisiert überarbeitet. Metadaten wie z.B. Namen und Color Codes der Apps werden über eine Verwaltungsoberfläche (Spring-Boot) gepflegt und dem Build-Prozess im JSON-Format zur Verfügung gestellt.

In Jenkins sind dafür parametrisierte Jobs eingerichtet, mit denen sich sowohl einzelne als auch alle Android oder iOS Apps veröffentlichen lassen.

Risikofreies Management von Abhängigkeiten bei Microservice Infrastruktur

Problemstellung: Wartungsintensive Abhängigkeiten im Build-Prozess führen zu Build- und Testfehlschlägen

Lösung: Microservices mit überschaubarem Wartungsaufwand automatisiert bauen, testen und deployen

Unser Vorgehen:

Auf Basis von Spring-Boot ist für die “taz - die tageszeitung” eine Microservice-Infrastruktur in Form von neun Anwendungen und vier Bibliotheken entwickelt worden. Um zu vermeiden, bei jeder Änderung an einer Bibliothek Versionsnummern in allen davon abhängigen Anwendungen hochzählen zu müssen, hat sich das Team für die Arbeit am Snapshot entschieden. Das manuelle Hochzählen von Versionsnummern in den Libraries und Anwendungen erfolgt nur noch bei größeren Updates.

Damit während des Build-Prozesses alle Anwendungen die aktuelle Version der jeweiligen Bibliothek beinhalten und aus unterschiedlichen git branches Artefakte erzeugt werden können, sind Jenkins Multibranch Pipelines erstellt worden. Bei der Ausführung der Pipeline Scripte werden die POM’s der Anwendungen geprüft und das Bauen von Bibliotheken gestartet, wenn Abhängigkeiten bestehen. Im Sinne des DRY ist diese Logik in eine Jenkins Shared Library ausgelagert und wird beim Bauen der Anwendungen mit den jeweiligen Parametern aufgerufen.

Der Vorteil besteht einerseits in der Risiko-Minimierung beim Auflösen der Abhängigkeiten und spart andererseits ca. 1500 Zeilen Code. Darüber hinaus wird der Build-Prozess wartungsarm gehalten, da Änderungen nur noch an einer Stelle vorgenommen werden müssen.

Electron Desktop Apps automatisiert Bauen und Testen

Problemstellung: Fehler treten in signierter Desktop App unter Windows aber nicht in der Entwicklungsumgebung unter macOS auf

Lösung: Oberflächentests auf signierten Desktop Apps mit unterschiedlichen Eigenschaften unter Windows automatisiert ausführen

Unser Vorgehen:

In einer Jenkins Multibranch Pipeline werden aus neuen git branches automatisch Jobs erstellt und bei jedem git commit ausgeführt. Sowohl der Checkout als auch der Build-Prozess der Windows Desktop Apps sind in einem Pipeline Script parallelisiert, um möglichst zeitnahes Feedback liefern zu können.

Da das Produkt an unterschiedliche Endkunden mit spezifischen Eigenschaften ausgeliefert wird, erzeugt der Build-Prozess Installationsdateien in drei Varianten, die auf dem Windows Build Server sequentiell installiert und mit Spectron getestet werden. Die Aktivierung der unterschiedlichen Features bzw. Installer-Varianten erfolgt über Änderungen an Konfigurationsdateien im JSON- und Properties-Format.

Der Vorteil für den Entwicklungsprozess liegt in der höheren Aussagekraft der erzeugten Artefakte. Die Testergebnisse liegen bereits 10-15 Minuten nach dem git commit vor. Die drei Varianten der erzeugten Artefakte (Windows Installer) sind damit getestet, veröffentlichungsfähig und könnten an die Endkunden ausgeliefert werden.

Testautomatisierung in der Cloud skalieren

Problemstellung: Sequentiell ausgeführte Oberflächentests auf mobilen Endgeräten sind sehr zeitintensiv

Lösung: Feedback-Zyklen beschleunigen durch Parallelisierung von Oberflächentests (Appium) auf mobilen Endgeräten in der Cloud (Test Object / Sauce Labs)

Unser Vorgehen:

Nach dem Bauen von iOS und Android Apps werden die Artefakte mit Jenkins parallel auf mehreren mobilen Endgeräten eines Cloud-Dienstleisters installiert und getestet. Die parallele Ausführung von langsamen Oberflächentests ermöglicht eine deutliche Beschleunigung der Feedback-Zyklen für Entwickler.

Zunächst wird mit curl und dem MD5 der Artefakte überprüft, ob die Datei bereits in der Test Object bzw. Sauce Labs Cloud existiert und gegebenenfalls hochgeladen. Mit curl, jq und dem MD5 der Artefakte wird die ID ermittelt und dem Appium-Test übergeben.

Die Verteilung der Tests auf die verschiedenen Geräte und Parallelisierung der Maven-Prozesse wird mit einer Jenkins Pipeline realisiert.