Suche
Implementierung von Continuous Delivery

6 Grundregeln, wie Sie Contiuous Delivery erfolgreich umsetzen

Sacha Labourey

©Shutterstock/ostill

Sie haben beschlossen, mit Continuous Delivery (CD) den ersten Schritt hin zur Optimierung Ihrer Softwareentwicklung („DevOps“) zu gehen? Indem man sicherstellt, dass die Teams sowohl für die Applikation als auch für die unterstützende Umgebung gemeinsame Ziele verfolgen, ist die Grundlage dafür geschaffen. Und wenn dann die Applikationsversionen ebenfalls produktionsbereit sind, fragt man sich: Was kommt als Nächstes? Jetzt können Sie die eigentliche Implementierung von CD in Angriff nehmen. Wie sollte man dabei vorgehen?

Da CD ein Prozess ist und nicht einfach durch Umlegen eines Schalters eingeführt werden kann, benötigt man zunächst einen Plan. Diesen müssen Sie umsetzen und darauf vorbereitet sein, die weitere Vorgehensweise zu überdenken, zu überarbeiten und zu erneuern. Durch CD wird die gesamte Kultur des Unternehmens verändert und eine bessere Methodik eingeführt, um bessere Software herzustellen. Dies lässt sich wohl nicht beim ersten Versuch erreichen. Aber man kann damit beginnen und man kann Erfolg haben, wenn man es langsam angehen lässt und einen Schritt nach dem anderen macht. Im Folgenden finden Sie einige Grundregeln, die sich für Unternehmen bei der Einführung von CD als erfolgreich erwiesen haben.

Wählen Sie zu Beginn ein kleines, handliches Projekt

Ein von Unternehmen häufig begangener Fehler ist, zu viel, zu schnell erreichen zu wollen. CD-Enthusiasten sind von der Methodik überzeugt und neigen dazu, große Vorteile schnell erzielen zu wollen, um das entsprechende Engagement des Unternehmens zu rechtfertigen. So setzen sie alles auf eine Karte und versuchen, ein kompliziertes Projekt zu meistern. Ein solcher „Big Bang“-Ansatz verspricht große Wirkung, kann aber auch spürbare Probleme mit sich bringen.

Eine bessere Methode ist es, mit einem kleinen Neuprojekt zu beginnen, an dem das Unternehmen CD ausprobieren und sich mit den neuen Verfahrensweisen vertraut machen kann. Versuchen Sie, einen neuen Bereich mit neuen Liefererwartungen auszuwählen, der nicht mit einer traditionellen Pipeline und alten Verfahrensweisen verknüpft ist. Kleine, inkrementelle Änderungen an Applikationen sind einfacher zu testen – und erlauben eine einfachere Fehlerbehebung, wenn etwas schiefgeht. Jede Änderung lässt sich schneller durch eine Pipeline pushen, so dass die Unternehmen kürzere und schnellere Pipeline-Durchläufe durchführen können, die messbare, positive Resultate bringen können.

Definieren Sie einen Prozess

Nachdem Sie Ihr Ausgangsprojekt ausgewählt haben, müssen Sie den Prozess definieren. Dies ist ebenso einfach wie das Aufschreiben der Verfahrensweise auf einer Tafel. Diejenigen unter uns, die das Buch The Phoenix Project von Gene Kim gelesen haben, sind mit diesem Schritt vertraut. Das im Buch beschriebene Unternehmen erlebte jedes nur denkbare Problem mit der Fertigstellung von IT-Projekten – bis Bill Palmer, VP of IT, Continuous Delivery einführte. Als ersten Schritt sollte jedes Teammitglied die Schritte des Lieferprozesses auf einem Whiteboard aufschreiben und sich Gedanken darüber machen, wie man sie zu einer durchgängigen Prozesskette verknüpfen kann. Anschließend machte sich das Team gemeinsam an die Arbeit, um einen Workflow zu erstellen und zu automatisieren.

Tatsache ist, dass man zwar großartige Tools anschaffen, ehrgeizige Ziele festlegen und das Team überzeugen kann, aber man kann erst dann anfangen, wenn man einen Prozess festgelegt,verstanden und die Rollen verteilt hat.

Sorgen Sie für eine Unternehmenskultur ohne Schuldzuweisungen

In seiner Beschreibung der Voraussetzungen für eine CD-Implementierung nennt Cyrille Le Clerc auch die Anforderung, dass die für Entwicklung, Qualitätssicherung und Operations zuständigen Teams gemeinsame Ziele verfolgen müssen. Dies ist von grundlegender Bedeutung. Aber die „Arbeit am Mitarbeiter“ ist hiermit noch nicht zu Ende. Bei der Implementierung von CD sollten Sie laufend überprüfen, dass Sie wirklich eine Unternehmenskultur ohne Schuldzuweisungen pflegen. Probleme werden bei jeder CD-Implementierung auftreten, und Ihr Unternehmen muss sicherstellen, dass diese auf positive Weise gelöst werden, ohne dass sich Mitarbeiter gegenseitig die Schuld geben. Erfolgreiche DevOps-Kulturen akzeptieren Misserfolge und fördern die Bereitschaft zum Risiko. Der Übergang zu CD ist ein Risiko und Ihr Team muss sich voll darauf konzentrieren, die Prozesse kontinuierlich zu verbessern.

Legen Sie Maßstäbe fest und messen Sie Ihren Erfolg

Der Forrester-Analyst Kurt Bittner ist nicht der einzige Visionär, der dafür plädiert, den Nutzen eines Projektes wiederholt zu quantifizieren. Aber ebenso wie andere zeigt er auf, was in einem Softwareentwicklungsprojekt gemessen werden muss und wie diese Messungen in dem Schritt des Prozesses anzuwenden sind. Tatsache ist, dass man nichts verbessern kann, was man nicht misst – so frühzeitig und so oft wie möglich. Daher ist es zu Beginn Ihres Weges hin zu CD wichtig zu entscheiden, was Sie verbessern wollen und wie Sie die Verbesserungen messen wollen. Legen Sie anschließend eine Reihe von Baseline-Messungen fest. Dann erst sind Sie startbereit.

Führen Sie „Configuration as Code“ ein

Ein wesentlicher Aspekt von CD ist die Möglichkeit zur Automatisierung Ihrer Konfiguration. Diese „Configuration-as-Code“ DevOps-Praktik gewährleistet die Konsistenz in Ihrem CD-Prozess und beseitigt Probleme, die immer dann durch den – potenziell inkonsistenten – Wiederaufbau Ihrer Konfiguration entstehen könnten, wenn Sie ein Release in die Produktion übernehmen wollen.

Bei der Implementierung von CD sollten Sie sicherstellen, dass Sie Tools einsetzen, die ein Konfigurationsmanagement ermöglichen – Tools von Chef, Puppet und anderen. Diese Tools werden in immer mehr DevOps-Projekten eingesetzt. Gemäß einer kürzlich im Auftrag von CloudBees durchgeführten DZone-Umfrage setzen 49 Prozent der Unternehmen ein Tool für das Konfigurationsmanagement und 48 Prozent ein Tool für die Versionskontrolle für Infrastruktur-Änderungen und Systemdefinition ein. Andererseits sind 73 Prozent bei mindestens der Hälfte ihrer Infrastruktur-Änderungen immer noch auf manuelle Skripts angewiesen.

Koordinieren Sie den Prozess

Die zuvor festgelegte Pipeline muss nun koordiniert werden. Dies ist ein langer Prozess, aber diese Schritte sollten Sie durchführen. Sie werden in einem Whitepaper von Andrew Phillips (Xebia Labs) und von Kohsuke Kawaguchi (CloudBees) beschrieben.

  • Sorgen Sie für reproduzierbare Builds – Konfigurieren Sie das Build-System so, dass ein sauberes, mit dem Arbeitsbereich des Build-Jobs verknüpftes Repository verwendet wird und verwenden Sie ein zentrales gemeinsames Repository für Build-Abhängigkeiten.
  • Nutzen Sie Build-Artefakte gemeinsam durch die Pipeline – Stellen Sie sicher, dass der in Frage kommende Artefakt von allen nachfolgenden Builds in Ihrer Pipeline verwendet wird.
  • Wählen Sie den richtigen Detaillierungsgrad für jeden Job – Verteilen Sie alle Schritte in der Pipeline auf mehrere Jobs, wodurch Sie Engpässe leichter erkennen können.
  • Visualisieren Sie die Pipeline – Erzeugen Sie eine klare, zugängliche Ansicht der Build Pipeline für eine reibungslose Statuskommunikation und Transparenz des Prozesses für die Geschäftsleitung und andere Interessenvertreter.

Schlussbemerkung

Die Umsetzung von CD kann anfangs eine große Herausforderung darstellen, aber die Mühe lohnt sich. Es sind Tools verfügbar, unter anderem zahlreiche frei verfügbare Jenkins-Plug-ins, mit denen sich die Aufgabe leichter bewältigen lässt. Mit etwas Mut und solider Vorausplanung können Sie ein CD-Projekt starten, das letztendlich greifbare Vorteile für Sie, Ihr Unternehmen und Ihre Kunden bringt.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.


 

Aufmacherbild: two men relay running sprinting von Shutterstock / Urheberrecht: ostill

Geschrieben von
Sacha Labourey

Sacha Labourey ist CEO und Gründer von CloudBees. Vor CloudBees war er CTO bei JBoss, nachdem JBoss von Red Hat übernommen wurde, war er Co-General Manager von Red Hats Middleware Division.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: