Suche
Expertencheck Teil 2

Continuous Delivery im Expertencheck: Softwarearchitektur und die richtige Tool-Auswahl

Melanie Feldmann

© Shutterstock / KreativKolors

Der Einfluss von Continuous Delivery reicht nicht nur bis in die Produktion, sondern auch nach vorne in den Designprozess. Wir haben unsere sechs Continuous-Delivery-Experten gefragt, welche Auswirkungen CD auf die Softwarearchitektur hat. Außerdem geben sie Tipps, mit welchen Tools man die CD-Toolchain am besten bändigen kann.

Event-Tipp: Bis zum Donnerstag, 11. Mai läuft noch das Frühbucher-Special für die DevOpsCon 2017: Jetzt anmelden und günstige Tickets sichern!

<

Lesen Sie den kompletten Schwerpunkt zum Thema Continuous Delivery im Java Magazin

Welche Auswirkungen hat Continuous Delivery (CD) auf die Softwarearchitektur?

Robin Bühler: Die Auswirkungen sind mannigfaltig. Es ist zentral, dass die gesamte Architektur auf gute und vor allem isolierte Testbarkeit ausgelegt wird und dass eine saubere Trennung zwischen Unit- und Integrationstests herrscht. Ein @SpringBootTest ist beispielsweise kein Unit-, sondern bereits ein Integrationstest! Des Weiteren sollte eine Anwendung so gestaltet sein, dass einzelne Teile unabhängig voneinander ausgerollt werden können. In diesem Kontext haben vor allem die Konzepte von strategischem Domain-driven Design, Microservices oder Self-contained Systems eine tragende Rolle inne. Weiterhin ist es von Vorteil, wenn eine Softwarearchitektur darauf ausgelegt ist, dass sie ein gutes fachliches und technisches Monitoring ermöglicht und dass einzelne Features zur Laufzeit ein- und ausgeschalten werden können (Feature Toggles). Insbesondere Eigenheiten der Zielinfrastruktur sollten einerseits berücksichtigt aber anderseits auch sauber von der Fachlichkeit isoliert werden.

Die Continuous-Delivery-Experten

Dr. Robin Bühler, IT Architect bei Allianz Managed Operations & Services

Bernd Greifeneder, CTO von Dynatrace

Christian Kühn, Systementwickler synyx

Mathias Meyer, CEO Travis CI

Oliver Wehrens, Chief Architect bei Deutsche Post E-Post Development

Eberhard Wolff, Fellow bei innoq

Bernd Greifeneder: Man bewertet die Automatisierbarkeit entlang der ganzen CD-Pipeline als genauso wichtig wie die eigentlichen Features. Als Beispiele nenne ich hier eine cloud-native Architektur, die automatische Skalierung, rollierende Updates und Failover erlaubt. Auch kann man große Features nicht ewig aus dem Code fernhalten, sondern sollte sie als Feature Flag ständig mitführen und für Kunden erst später freischalten. Architekten kümmern sich nun auch von Anfang an mehr um Monitoring, sei es Log-, Telemetriedaten- oder Code-Level-Applikationsmonitoring.

Christian Kühn: Vielen Entwicklern und Betreibern moderner Software werden erst durch automatisches Testen und Deployen Schwachstellen ihrer Software klar. Es entsteht ein gewisser Zwang, Software besser testbar und vor allem erweiterbar zu schreiben, um häufiger neue Versionen und Iterationen schaffen – und auch mal zurückrollen – zu können.

Mathias Meyer: Viele Unternehmen und Teams, die vornehmlich an großen Apps arbeiten – den Monolithen –, werden sowohl mit der Einführung als auch mit der langfristigen Adaptierung von CD Probleme haben. CD setzt vornehmlich auf die Fähigkeit, jederzeit und schnell nach Code in Produktion zu bekommen. Gerade monolithische Apps stehen hier mit komplexen Test-Suites und Setups im Weg. Dazu kommt, dass die Komplexität dieser Apps über die Zeit nur steigen kann. Neue Tests kommen hinzu, neue Features bedürfen neuer Dependencys und noch komplexerer Setups. Das ist vor allem für die Testumgebung schädlich, hat aber auch negativen Einfluss auf die Komplexität der Produktionsumgebung.

Die Antwort heißt nicht notwendigerweise Microservices. Diese bringen eine ganz andere Art der Komplexität mit sich, vor allem in den Bereichen Kommunikation und Kollaboration. Aber meiner Erfahrung nach ist die verbreitete Lösung – und auch die am ehesten gangbare – Monolithen über die Zeit auseinander zu brechen oder neue Dienste um den Monolithen herum zu bauen.

Oliver Wehrens: Die Architektur muss in der Lage sein, mit verschiedenen Versionen der gleichen Software zu arbeiten. Wird eine neue Version deployt, wird dies typischerweise wellenweise erfolgen. Ankommende Requests müssen auch von eventuell noch nicht aktualisierten Instanzen bearbeiten werden können. Dieses verschärft sich in Microservices-Umgebungen. Ein verstärkter Fokus auf Resilience geht typischerweise einher, da Services ohne Benachrichtigung sich verändern. Ein Mantra ist hier: Design for failure. Dies hat massive Auswirkungen auf die Architektur.

Eberhard Wolff: Bei der Aufteilung in Komponenten kann jede Komponente eine eigene Deployment-Einheit werden. Dieser Microservices-Ansatz erleichtert Continuous Delivery, weil das Deployment kleinerer Einheiten einfacher ist. Continuous Delivery kann auch unterstützt werden, indem Technologien genutzt werden, die ein einfacheres Deployment erlauben. Dazu zählen in der Java-Welt Fat JARs, weil dann nur ein Artefakt deployt und konfiguriert werden muss, während sonst zusätzlich zur Anwendung noch ein Application Server zu konfigurieren und zu installieren ist.

Welche Werkzeuge nutzt du für CD?

Bernd Greifeneder: Atlassian Jira, Quickbuild, Jenkins, Ansible, Dynatrace für das Monitoring, Opsgenie, Selenium, Appium, Dynatrace Davis mit Alexa und Slack, Gradle, Artifactory, git, AWS, einen eigenen Cloud-Orchestration-Server, eigene Testautomatisierung, Kaspersky, Sonar, Bullseye, Blackduck, …

Christian Kühn: Code-Versionierung mit git, Build-Tools sind Jenkins und gitlab-ci, Test- und Codequalitäts-Frameworks wie SonarQube, Repositories für Artefakte mit nexus und Artifactory sowie für das Job-Scheduling Rundeck.

Wir benutzen diese Tools voll-integriert an- und ineinander. Die Toolchains werden teilweise automatisch getriggert, z. B. wenn Code in git eingecheckt wird, teilweise händisch durch ChatOps-Befehle oder aus Rundeck. Zusätzlich legen wir großen Wert auf Monitoring und Logging. Idealerweise sollte auch nicht nur Code, sondern auch die CD-Tools selbst automatisiert getestet werden, um zeitaufwendige Fehlersuche zu vermeiden, die den kompletten Betrieb aufhalten würde. Die Konfiguration der Tools wird größtenteils mit Puppet gemanagt. Wobei Puppet selbst großteils durch die CD-Toolchain läuft, quasi gegenseitige Unterstützung von Config-Management und CD-Toolchain.

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Mathias Meyer: Unser Workflow dreht sich um GitHub, Slack, Heroku und –natürlich – Travis CI, was sich quasi selbst baut und in die Produktion bringt. Unser Team arbeitet vornehmlich mit Pull Requests auf GitHub, manche kurz- andere langlebig. Für einige Apps, z. B. unser auf  Ember.js basierendes Web-Frontend, haben wir ein Setup, das Pull Requests auf separate Apps – eine neue App pro Pull Request – deployt. Damit kann das ganze Team schnell und einfach Änderungen anschauen und Feedback geben. Gerade für unser UI hat diese Änderung sehr positive Auswirkungen gehabt, um Änderungen schnell zum Kunden zu bekommen.

Jeder kann bei uns im Team jederzeit die meisten unserer Apps in die Produktion deployen. Wir haben ein ChatOps-Setup, das ermöglicht, beliebige Zweige unserer GitHub-Projekte nach Staging oder Production zu deployen. Dieses Setup hat den Vorteil, den Einstieg für neue Entwickler sehr einfach zu gestalten. Zudem erhöht es die Sichtbarkeit von Deployments und wer wann was wohin deployt hat.

Oliver Wehrens: Wir nutzen Teamcity, Puppet und RPMs/VM/Docker Images.

Eberhard Wolff: Vor allem die Nutzung von Docker und Docker-Schedulern wie Kubernetes nimmt zu. Anwendungen in Docker Images zu verpacken, erleichtert Continuous Delivery erheblich. Mit Werkzeugen wie Concourse hält Docker Einzug in Continuous-Integration-Werkzeuge, die eine wesentliche Grundlage für Continuous Delivery sind. Im Bereich Tests gibt es eine Vielzahl an Werkzeugen. Das Vertrauen der Kunden in die Tests ist zentral. Daher sollten Kunden automatisierte Tests für sie nachvollziehbar beschreiben. Dazu sind auch eigene Lösungen denkbar, die beispielsweise Excel-Dateien auslesen.

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.