Willkommen bei unserer Tech Blog Serie: Continuous Delivery von Microservices in AWS

Heutzutage erwarten Kunden, dass IT-Unternehmen neue Funktionen schneller als je zuvor bereitstellen. In der Vergangenheit reichte es oft noch, dass Unternehmen vierteljährlich eine neue Version eines Systems lieferten. In den letzten Jahren mussten aber viele von ihnen auf monatliche Releases umstellen, um die Kundenbedürfnisse zu erfüllen. Das scheint immer noch nicht genug zu sein. Heute erwarten Kunden einen kontinuierlichen Fluss neuer Features, wie es die großen IT-Unternehmen Google und Co. schon seit Jahren tun.

Es handelt sich also um eine Transformation des Software Delivery Process, die von manuellen, stundenlangen Implementierungen hin zu täglichen automatisierten Releases reicht. Das ist eine große Herausforderung für viele Unternehmen und es sind gewisse organisatorische und technische Vorbereitungen notwendig, bevor mit dem Übergang begonnen werden kann. Bedenken Sie auch, dass es keine Abkürzungen gibt, die wir von vierteljährlichen auf tägliche Releases anwenden können - es ist vielmehr eine kontinuierliche Verbesserung, die zu Continuous Delivery führt. Wir müssen von vierteljährlichen zu monatlichenzu wöchentlichen zu täglichen Releases wechseln. Einige Unternehmen sind möglicherweise schon mit monatlichen Releases zufrieden, während andere den Druck verspüren, täglich zu releasen. Egal, was Ihre Ziele sind, die Lösung ist fast die gleiche.

Mit dieser Tech-Blog-Serie möchten wir die grundlegenden Konzepte von Continuous Delivery diskutieren und Schritt für Schritt praktische Sessions zum Aufbau einer einfachen Delivery Pipeline für Java Microservices in der Amazon Web Services (AWS) Cloud anbieten. Wir haben die Serie in 3 größere Teile aufgeteilt und werden alle 2 bis 3 Wochen einen neuen Blogeintrag veröffentlichen. Werfen wir einen Blick auf die Bereiche, die wir abdecken wollen:

  • Teil 1: CI/CD-Grundlagen – Configuration Management, Continuous Integration und die Delivery Pipeline

  • Hands-On session: One-Click Deployment eines Microservices auf AWS

  • Teil 2: Verwalten der Infrastruktur - Umgebungen in AWS und das Verwalten von Daten

  • Hands-On: One-Click Deployment einer AWS-Umgebung inklusive der Anwendung

  • Teil 3: Entwicklungsprozess - Branching- und Teststrategien für CD

  • Hands-On: Vollständig integriertes, getestetes und verifiziertes One-Click Deployment

  • Zusammenfassung: Wie man Features zu 100% automatisiert veröffentlicht

Bevor wir die Voraussetzungen für die Einführung von Continuous Delivery besprechen, möchte ich den Umfang dieser Blogserie definieren.

Ich bin mir bewusst, dass es verschiedene Definitionen von Continuous Delivery gibt. Im Fall dieses Blogs handelt es sich um Continuous Delivery im Sinne der technischen Möglichkeit, Features kontinuierlich und automatisiert in allen Phasen der Deployment-Pipeline bereitzustellen. Dies bedeutet nicht, dass Sie tatsächlich täglich neue Software veröffentlichen - was als Continuous Deployment zu bezeichnen wäre. Dies bedeutet auch nicht, dass Ihr Software-Implementierungsansatz dazu bereit ist. Es sollte jedoch keine Hürden und Schwierigkeiten geben, wenn Sie ein neues Feature bereitstellen möchten. Und genau das versuchen wir zu erreichen. Indem Sie neue Versionen sicher und einfach bereitstellen und von einer Deployment Stage auf die nächste übertragen, wird sich die Release-Häufigkeit von selbst beschleunigen.


Bekannte beliebte Definitionen sind:

Continuous Delivery ist eine Softwareentwicklungsdisziplin, in der Sie Software so erstellen, dass diese jederzeit in Produktion deployed werden kann. Übersetzt auf Deutsch, Original von Martin Fowler, https://martinfowler.com/bliki/ContinuousDelivery....

Continuous Delivery ist die Fähigkeit, Änderungen aller Arten - einschließlich neuer Funktionen, Konfigurationsänderungen, Fehlerbehebungen und Experimenten - sicher und schnell und auf nachhaltige Weise in Produktion oder in die Hände der Benutzer zu bringen. Übersetzt auf Deutsch, Original von Jez Humble, https://continuousdelivery.com/

Um es zusammenzufassen, dies sind die zentralen Begriffe und Abkürzungen, die ich im Blog verwenden werde:

Continuous Integration (CI): Code in einer bestimmten Umgebung integrieren, erstellen und testen

Continuous Delivery (CD): Mechanismen, die das kontinuierliche und automatisierte Deployment von Systemen, Komponenten, Änderungen und Funktionen in bestimmten Umgebungen ermöglichen

Continuous Deployment: Tägliche oder regelmäßige Bereitstellung neuer Funktionen für die Produktion

Wenn ich die Abkürzung CI/CD verwende, bezieht sich diese auf allgemeine Ansätze und Konzepte, die für Continuous Integration und Continuous Delivery gelten.

Voraussetzungen für Continuous Delivery (CD)

Während viele Unternehmen bereits gut vorbereitet sind, müssen andere Firmen noch Teile ihrer Organisation und Implementierungsansätze ändern und verbessern, bevor sie mit den ersten Schritten zu CD beginnen. Werfen wir einen Blick auf die Voraussetzungen, bevor wir mit der Einführung der wesentlichen Konzepte von CD fortfahren.


Der organisatorische Teil von CD

Ich möchte hier nicht ins Detail gehen, da dies ein Tech-Blog ist, aber es gibt organisatorische Einschränkungen, die Ihnen bei der Einführung von CI/CD Probleme bereiten könnten. In vielen Unternehmen gab es eine Trennung zwischen Entwicklung und Betrieb. Wenn Ihr Unternehmen immer noch den Ansatz hat, Software Pakete von der Entwicklungsabteilung über den „Zaun“ zu Operations zu schmeißen, dann werden Sie Schwierigkeiten haben, selbst einfache CI-Mechanismen einzuführen. Wenn Ihr Unternehmen bereits auf grundlegende DevOps-Konzepte umgestellt hat, dann sollte Ihnen die Umstellung einfacher fallen. Sie sollten in der Lage sein, die folgenden Fragen mit JA zu beantworten, um auf der organisatorischen Seite alle Voraussetzungen für die Implementierung von CI und CD zu schaffen:

  • Arbeiten Entwickler und Operations-Experten in einem Team oder arbeiten sie zumindest eng zusammen?
  • Hat Ihr Team Zugriff auf CI/CD-Tools und darf Builds und Bereitstellungen für Test- und Staging-Umgebungen selbst durchführen?
  • Arbeiten Sie nach agilen Entwicklungsmethoden, die es ermöglichen, Software zumindest theoretisch regelmäßig zu releasen?


Mehrere Umgebungen und Entwicklungs-Stages

Um CI/CD zu ermöglichen, müssen mehrere Umgebungen verfügbar sein. Von der lokalen Entwicklungsumgebung für die Entwickler bis hin zur offiziellen Produktionsumgebung kann es verschiedene Umgebungen geben. Es hängt von den Bedürfnissen des Projekts oder des Produkts ab, aber im Allgemeinen ist mindestens eine Entwicklungs-, Test- und Staging-Umgebung erforderlich.

Wenn mehrere Umgebungen vorhanden sind, kann jede für weitere Tests und Integration der Software verwendet werden. Mit jedem Schritt wächst die Reife des Deployment Packages und das Risiko für den Release in Produktion sinkt.


Gut definierte Quality Gates von Stage zu Stage

Um sicherzustellen, dass die Qualität von Stage zu Stage zunimmt, müssen gut definierte Quality-Gates und -Tests implementiert werden. Zu Beginn können die Tests und Kontrollen manuell sein - aber sie müssen jedes Mal ausgeführt werden. Keine Ausnahmen - keine schnelles direktes Release in die Produktion. Auf dem Weg zu CD müssen mehr und mehr Schritte der Quality Gates automatisiert werden. Quality Gates können Komponenten- und Integrationstests, Data Quality Checks, nichtfunktionale Tests, Code Quality Checks und mehr umfassen.


Alle Dokumente müssen eingecheckt sein

Eine der Grundvoraussetzungen für CI/CD ist ein gut integriertes Versionskontrollsystem (CVS) - vorzugsweise eine GIT Distribution. Eine generelle Regel ist zu befolgen: jede Datei, jede Konfiguration, jedes Stück Code oder andere Dinge, die für das Funktionieren der Software relevant sind, müssen eingecheckt werden. Dies ist sehr wichtig. Dadurch garantieren Sie, dass Ihre Tags und Branches alles Notwendige enthalten.

Anspruchsvoller aber ebenso wichtig ist es, größere Systeme in verschiedene Repositories und Ordnerstrukturen aufzuteilen. Es gibt keine allgemeine Regel, aber Sie sollten verschiedene Repositories für verschiedene Systeme und unabhängige Komponenten wie Microservices verwenden. Wenn andererseits eine Datenbank ein wesentlicher Teil eines (Micro-)Services ist, sollten sich die Skripte zum Erstellen und Füllen der Datenbank im selben Repository befinden wie der Microservice. Das Verwalten von Komponenten/Systemen in verschiedenen Repositories führt zu einer losen Kopplung, die es uns ermöglicht, sie unabhängig voneinander zu implementieren.


Klare Regeln für Branching und Feature Switches

Damit CI/CD funktionieren kann, müssen Entwickler mindestens einmal am Tag einchecken – und zwar bevorzugt in den Master Branch. Auf der anderen Seite muss die Codebasis immer in einem Working State sein. Daher müssen Entwickler wissen, wie sie gegen den Master Branch entwickeln können oder wenn nötig mit Release-, Feature- oder Team-Branches umgehen sollen. Aber noch wichtiger: Sie müssen wissen, wie sie Features entwickeln und einchecken können, ohne bestehende Funktionen in Mitleidenschaft zu ziehen. So können Entwickler z.B. Feature Switches für unfertige, neue Funktionen für vorhandene Komponenten verwenden, um sie zu deaktivieren, bis sie für die Veröffentlichung bereit sind.

Alles bereit?

Wenn die Voraussetzungen Sie nicht zu sehr beunruhigen, dann würde ich sagen, dass Sie bereit sind, tiefer in CI/CD einzutauchen. Im nächsten Blog Post werden wir die Grundlagen von CI/CD besprechen und anfangen, an unserer Delivery Pipeline zu arbeiten.


Walter Pindhofer

Über den Autor:

Walter Pindhofer
Chief Solution Architect / Delivery Manager


In seiner Rolle als CSA ist Walter Pindhofer verantwortlich für die Entwicklung und Implementierung passender Lösungen für namhafte Unternehmen. Als großer Fan von Continuous Improvement konzentriert er sich derzeit auf DevOps, CI / CD und agile Methoden.

Beschleunigen Sie Ihre Delivery!

Von Continuous Integration bis DevOps bieten wir einen strategischen Ansatz, um die Liefergeschwindigkeit und Qualität unserer Kunden zu verbessern:

  • Die Automatisierung entlang der Delivery-Pipeline beschleunigt die Zeit, die ein Feature vom Check-In bis zum Release in Produktion benötigt.

  • Unsere bewährten Methoden und Best Practices ermöglichen einen sicheren Übergang von der traditionellen Softwareentwicklung zu Continuous Delivery.
Next

TECH BLOG - Einleitung 1. Teil: CI/CD Antipatterns

09.04.2018, 12:52
#

Ich möchte den Tech Blog mit einem Post über CI/CD Patterns und Antipatterns beginnen. Ich denke, dass die meisten hier angeführten Dos and Don’ts gut bekannt sind, dennoch halten sich aber viele der Antipatterns immer noch hartnäckig. Wenn Sie ein Neuling in Bezug auf CI/CD sind, dann sollte Ihnen die Liste zumindest helfen, die grundlegenden Konzepte hinter CI/CD zu verstehen und die gröbsten Fehler von Beginn an zu vermeiden.

Mehr erfahren