Kennen Sie das?

• Als Developer haben Sie ein Feature umgesetzt. Bei der Übergabe fällt im Gespräch mit IT Operations der allseits bekannte Satz “…also bei mir läufts ?!?…”
• Als IT-Operator sollen Sie ein Artefakt mit neuen Bibliotheken deployen, das in Ihrer Produktionsumgebung erhebliche Probleme verursacht.

Ja? Herzlich willkommen in unserer Projektwelt. Trotz über 20 Jahren Entwicklererfahrung in den unterschiedlichsten Projekten und Unternehmen, erleben wir bestimmte Problemstellungen als äußerst änderungsrestistent.

Spannende Features werden entwickelt und liegen als “totes Kapital” in der Deployment-Pipeline, weil diese nicht schnell genug in Produktion gebracht werden können. Für Unternehmen kann das den Verlust von Geld, Wettbewerbsfähigkeit, Ansehen und im schlimmsten Fall Ihrer Existenz bedeuten. Schnelles Deployment schafft auch Flexibilität und Freiraum für neue Ideen, die dank des kürzeren “time to market” kundenseitig sehr schnell einen Mehrwert liefern und den vielleicht entscheidenden Wettbewerbsvorteil verschaffen. Unternehmen wie Amazon, Google und Co. stellen neue Deployments innerhalb von Sekunden und das mehrfach am Tag produktiv. Wie sieht es in Ihrem Unternehmen aus? Haben Sie sich schon einmal überlegt, wie lange Sie für die Produktivsetzung nur einer geänderten Zeile Code tatsächlich benötigen?

Ein weiteres Problem sind Unterschiede in den Laufzeitumgebungen für Entwicklung, Test und Produktion. Mit Hilfe einer geeigneten “Paketierung” (Docker-Container) können identische Laufzeitumgebungen in jedem Staging-Level bereitgestellt werden. Diese beinhalten die einzelne Applikation, das komplette OS, und alle übrigen notwendigen Laufzeitkomponenten.

Laufzeitumgebungen werden oft manuell konfiguriert und selten dokumentiert. Damit einher geht ein deutlich erhöhtes Risiko, dass sich das produktive Deployment erheblich verzögert oder sogar scheitert. Development ist heute bereits in der Lage mit agilen Vorgehensmethoden wie Scrum und einer starken Automatisierung des Build- und Test-Prozesses schnell auszuliefern. Somit stellt die Automatisierung der Infrastruktur (z.B. Server, Datenbank, Netzwerk etc.) aka. “Infrastructure-as-code” den nächsten logischen Schritt dar. Der dafür implementierte Code wird – wie auch der Applikations-Code – in einem Repository versioniert.

Aus all diesen Gründen haben wir uns entschieden, unsere reine Entwickler-Brille abzulegen, und DevOps in unsere Projekte zu tragen. Neben der Adressierung der benannten Pain points, war es für uns wichtig zu verstehen, wie und warum die “andere Seite” – das IT Operations – tickt und wie uns der zunächst sehr unübersichtlich erscheinende Zoo an Technologien und Frameworks dabei helfen kann, die Kluft zwischen diesen beiden IT-Bereichen zu überbrücken.

Zielarchitektur für unser Projekt

Ein Produktartefakt wird in Form eines oder mehrerer Docker-Container entwickelt, d.h. neben dem Applikationscode enthalten diese auch das Betriebssystem und alle weiteren, zum Betrieb notwendigen Abhängigkeiten (Libraries, 3rd Party Binaries, etc.). Der Build der Applikation, das Paketieren in einen/mehrere Docker Container und alle Tests werden automatisiert über einen Continuous Integration Prozess (CI) ausgeführt. Das entstehende Produkt-Artefakt wird automatisiert in die Staging-Umgebung deployed (Continuous Delivery – CD), wo z.B. bei Bedarf auch der finale Abnahmetest stattfinden kann. Die letzte Stufe ist das automatisierte Deployment des weiterhin unveränderten Produktartefaktes in die produktive Umgebung. Man spricht in diesem Zusammenhang auch von Continuous Deployment.

In einer Serie weiterer Blog-Posts beschreiben wir unsere Umsetzung der obigen Zielarchitektur anhand der folgenden 3 Themenblöcke:

• Aufbau der notwendigen Infrastruktur
• Aufbau der CI/CD-Pipeline
• Finalisierung der Continuous Deployment Pipeline durch Einbinden einer Orchestrierungsplattform (OpenShift)

Wir freuen uns auf Feedback/Kommentare!