Ab und zu kommen Wünsche, die sich extrem einfach mit Kubernetes umsetzen lassen würde, aber …​
Kubernetes ist viel zu komplex!
Wir haben kein Kubernetes!
Es ist doch nur ein Server (aber Ausfallsicherheit brauchen wir schon) …​

Wie könnte also ein unterbrechungsfreies Deployment aussehen, wenn lediglich Docker und Docker Compose zur Wahl stehen, und was sind die Tradeoffs, die damit einher gehen?
Schauen wir es uns an einem praktischen Beispiel an.

GitLab hat mit GitLab CI eine angenehme Integration von Builds in die Repositoryverwaltung. Damit lassen sich Pipelines umsetzen, die schnelles Feedback liefern und damit helfen, die Software- und Systemqualität zu verbessern.
Die GitLab CI Runner helfen dabei, den Build zu skalieren, damit es auch hier nicht zu unnötigen Verzögerungen kommt.

Doch was, wenn der Wunsch besteht, dass genau das passiert? Es soll bis zu einem gewissen Zeitpunkt verzögert werden, da die bisherige Anwendung noch Session-basiert ist, und zu einem Zeitpunkt mit der geringsten Wahrscheinlichkeit für Störungen das Deployment erfolgen soll.

Im heutigen Software-Entwicklungsalltag ist Security ein entscheidendes Thema. Moderne Java-Anwendungen bestehen zu einem erheblichen Teil aus Fremdbibliotheken. Diese sollten regelmäßig auf den neusten Stand gebracht werden, auch um möglichen Sicherheitslücken entgegenzuwirken.

Wie im Vorgängerartikel Build-Warnungen bei Dependency-Updates beschrieben, machen externe Abhängigkeiten oft über 90% des Codes in Microservices aus. Neben der Aktualität der Bibliotheken ist es besonders wichtig, bekannte Sicherheitslücken (CVEs) zu erkennen und rechtzeitig Gegenmaßnahmen einzuleiten.

Das OWASP Dependency-Check-Maven-Plugin bietet eine praktische Lösung, um aus dem Build-Prozess heraus auf mögliche Sicherheitslücken in Abhängigkeiten aufmerksam zu machen. Im Folgenden stelle ich vor, wie sich das Plugin in eine Spring-Boot-Anwendung sowie eine GitLab CI-Pipeline integrieren lässt.

Zur Abbildung eines speziellen Freigabeprozesses von Dokumentvorlagen und Textbausteinen entstand der Wunsch, manuell zu selektieren, welche Dateien von einer Entwicklungsstage in die nächste transportiert werden.
Als System zur Versionskontrolle sollte das bisher genutzte Subversion (SVN) durch git abgelöst werden.

Wir haben uns dazu zwei Varianten im Kontext des git Versionskontrollsystems überlegt und stellen diese im folgenden vor.
Im Fazit wird schließlich betrachtet, wie eine gänzlich alternative Herangehensweise aussehen könnte.

Azure DevOps ist der Nachfolger des Microsoft Team Foundation Server (TFS). Inbegriffen sind Buildserver (CI), Version Control (git), Verwaltung manueller Testpläne und Artefaktauslieferung (CD).
Die Features von Azure DevOps können dabei je nach Bedarf aktiviert werden.

Im folgenden soll eine Angular Webanwendung mit Azure DevOps als Buildserver gebaut werden. Damit der Build gemeinsam mit der Software versioniert und entwickelt werden kann, wird die Buildkonfiguration im YAML Format als Azure Pipeline im Repository abgelegt.

Bei Drone CI handelt es sich um einen OpenSource continuous integration (CI) Server. Dabei setzt Drone CI auf die Ausführung des Builds mittels Containern. Typischerweise werden dabei Docker oder Kubernetes als Container Plattform eingesetzt.

Eine Buildpipeline wird in YAML definiert, dabei können sowohl services definiert werden, die im Build verwendet werden, als auch persistente volumes und natürlich die Buildabläufe als steps.

Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus. Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden. Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.

Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.