SITIC Online Sharing, Mittwoch 1. September 2021, 10 – 12 Uhr

Continuous Delivery in inhomogenen Architekturen

Hintergrund

CI/CD ist die bekannte Grundlage für schnelles Iterieren von Lösungen. Eine ständig wachsende und sich verändernde Architektur mit inhomogenen Technologie-Stacks machen diese Aufgabe zu einer Herausforderung. DevOps, Entwicklung und Management müssen in der CI/CD-Strategie übereinstimmen, um einen nahtlos-automatisierten Deployment-Prozess sicherzustellen.

Bei fortgeschrittener Automatisierung der Auslieferung von Software verschmelzen Continuous Integration und Continuous Deployment zu Continuous Development. Dieser Begriff verdeutlicht die Idee, unproblematische Änderungen ohne manuelle Intervention von der Maschine des Entwicklers bis ins Produktivsystem zu deployen (siehe Seitenspalte).

Dieses Ziel hat jedoch einen Preis: Automatisierte Tests in Prüf- und Release-Phasen müssen Vollständigkeit und eine hohe Qualität aufweisen. Sie manifestieren auch die gemeinsame Deployment-Strategie, welche die Entscheidungen von der Architektur über die Entwicklung bis zum Betrieb beeinflusst.

Zielsetzung

Wir werden eine Auswahl der folgenden Fragen diskutieren, welche von den Teilnehmenden vorab priorisiert werden:

  • Welche Systeme (Stages) durchlaufen Änderungen bei CI/CD? Wie kombiniert man allenfalls verschiedene Architekturen mit unterschiedlichen Stages?
    – In welchen Punkten unterscheidet sich das Staging/Testumgebung von der produktiven Umgebung? In welchen besser nicht?
  • Wie stellen wir sicher, dass ein neues Deployment in inhomogenen Architekturen wirklich funktioniert? Daraus folgen die Kriterien für einen automatischen Rollback bzw. manuelle Intervention
    – Wie gelingt es möglichst viele Bugs schon in der CI-Phase abzufangen? Wie können Integrationstests auch in inhomogenen Architekturen helfen?
    – Wann ist Canary Deployment sinnvoll?
    – Wofür helfen Parametrisierungen (Variablen) in Pipelines? Wann sind sie eine Gefahr für die Reproduzierbarkeit?
  • Wie werden Datenmigrationen umgesetzt?
    – Wird immer ein vollständiges Backup erstellt?
    – Was wird unternommen wenn Datenmigrationen fehlschlagen?
    – Wie werden Datenmigrationen zurückgerollt?
    – Wie ändern sich die Antworten auf obige Fragen in verteilten/Service-lokalen Datenbanken?
  • Governance
    – Welche Best-Practices müssen in der Entwicklung stringent befolgt werden, um Continuous Delivery zu ermöglichen?
    – Welches Access-Modell wird auf die CI/CD-Pipelines angewandt? Welche Rollen (von RBAC) werden unterschieden?
    – Wie kann in der Entwicklung mit möglichst produktiv-ähnlichen Daten gearbeitet werden?

Vorbereitung

Von den Teilnehmenden wird erwartet, dass sie sich durch Studieren eines Beispiels einer CI/CD-Pipeline vorbereiten. Dieses wird ihnen zusammen mit der Teilnahmebestätigung zugestellt.

Teilnehmende

Willkommen sind Business IT Professionals, welche im Unternehmen Aufgaben der Digitalisierung, IT-Architektur oder DevOps wahrnehmen.

Moderation

Fachliche Moderation: Simon Wehrli
Technische Moderation: Florence Neumann

Agenda

  • (30’) Diskussion des vorgängig versendeten Beispiels einer CI/CD-Pipeline.
  • (50’) Diskussion präferenzierter Fragen in Gruppen
  • (30’) Interaktive Sammlung der Erkenntnisse
  • (10’) Priorisierung der Key-Takeaways

Nachlese

Die Nachlese umfasst eine Aussicht auf mögliche Langzeit-Ziele für CI/CD und DevOps im Allgemeinen.

Anmeldung

Verbindliche Anmeldung bitte via Email an kurt.wehrli@sitic.org

Kosten

Für SITIC-Mitglieder ist die Teilnahme im Rahmen der Jahresmitgliedschaft unentgeltlich.
Nicht-Mitgliedern werden 375 CHF in Rechnung gestellt, der Zahlungseingang muss vor dem Sharing erfolgen.

Was versteht man unter CI/CD?

Photo 101380691 © Xin Hua | Dreamstime.com

Unter CI/CD versteht man ein Paradigma, welches alle Phasen der Anwendungs-Entwicklung weitestgehend automatisiert und den Benutzern regelmäßig Updates zur Verfügung stellt.

Die Hauptkonzepte von CI/CD sind Continuous Integration, Continuous Delivery und Continuous Deployment. CI/CD löst manche Probleme, welche die Integration von neuem Code verursachen kann.

Mehr bei Red Hat