“Kontinuierliche Lieferung vebessert die Geschwindigkeit und Qualität der Auslieferung, und hilft zugleich die Kultur zu verbessern, Burnout und Mühsal in der Entwicklung zu vermeiden.”
– Das Mindset von DevOps. Accelerate: 24 Schlüsselkompetenzen, um leistungsstarke Technologieunternehmen zu entwickeln und zu skalieren
Wir, die Unterzeichner, sind der Meinung, dass eine Minimale Definition von Continuous Delivery (CD) erforderlich ist, um den Ablauf der Software-Lieferung zu verbessern und die oben genannten Ergebnisse zu erzielen. Obwohl unsere Kontexte unterschiedlich sein mögen, gibt es universelle Praktiken, die allen Situationen und Teams gemeinsam sind. Indem wir diese definieren, können wir:
- neue Praktiker auf konsistente Art und Weise einführen
- die technischen Praktiken, die CD ausmachen, diskutieren
- uns gegenseitig helfen, unsere derzeitigen Fähigkeiten zu verbessern
Nur wenn wir Kernpraktiken umsetzen, können wir die Vorteile von Continuous Delivery für uns nutzen.
Die untenstehenden Praktiken sind das Minimum, ein Ausgangspunkt. Das erwartete Ergebnis ist eine kontinuierliche Verbesserung der Geschwindigkeit, Qualität und Sicherheit der Lieferpipeline.
Kontinuierliche Lieferung
Kontinuierliche Lieferung (Continuous Delivery, CD) ist die technische Disziplin, bei der alle Änderungen auf sichere Weise in einem stets gleichen Verfahren bereitgestellt werden. CD deckt ein breites Spektrum von Aktivitäten ab, je nach den Besonderheiten des Liefergegenstandes. Es gibt jedoch bestimmte Verhaltensweisen und Fähigkeiten, die in jedem Kontext erfüllt sein müssen, um als “kontinuierliche Lieferung” zu gelten.
Die für CD erforderlichen Mindestaktivitäten sind:
- Kontinuierliche Integration verwenden
- Die Anwendungspipeline ist die einzige Möglichkeit zur Lieferung in einer beliebigen Umgebung.
- Die Pipeline entscheidet über die Freigabefähigkeit von Änderungen, ihr Urteil ist endgültig
- Die von der Pipeline erstellten Artefakte entsprechen immer der der organisationseigenen “Definition für deploybar”.
- Unveränderliche Artefakte. Keine menschlichen Änderungen nach der Übergabe an cas CD-System.
- Jegliche Arbeiten an Features werden eingestellt, wenn die Pipeline defekt ist.
- Produktionsähnliche Testumgebung
- Rollback bei Bedarf
- Anwendungskonfiguration wird gemeinsam mit dem Artefakt ausgeliefert
Kontinuierliche Integration
Bei der kontinuierlichen Integration (continuous integration, CI) wird die Arbeit sehr häufig in den Stamm (trunk) der Versionskontrolle integriert und überprüft, ob die Arbeit nach bestem Wissen und Gewissen freigegeben werden kann.
Die für CI erforderlichen Mindestaktivitäten sind:
- Trunk-basierte Entwicklung
- Die Arbeit wird mindestens täglich in den Stamm integriert
- Die Arbeit wird vor dem Zusammenführen mit dem Trunk automatisch getestet.
- Die Arbeit wird beim Merge automatisch mit anderen Arbeiten getestet
- Alle Arbeiten an Features werden gestoppt, wenn der Build defekt ist.
- Neue Arbeiten machen die bereits gelieferten Arbeiten nicht kaputt
Trunk-basierte Entwicklung
Die trunk-basierte Entwicklung ist das branching Modell, das erforderlich ist, um die Definition von CI zu erfüllen. Es verhindert den Verlust von Arbeit, das Risiko von verfälschtem oder defektem Code bei der Lösung von Merge-Konflikten besteht und auch die (Lean-) Verschwendung durch Bewegung, die die Batchgröße erhöht.
- Die für TBD erforderlichen Mindestaktivitäten sind:
- Alle Änderungen werden in den Stamm integriert.
- Wenn Zweige aus dem Stamm verwendet werden:
- Sie stammen aus dem Stamm
- Sie werden wieder in den Stamm integriert
- Sie sind kurzlebig und werden nach dem Merge entfernt.
Warum haben wir das gebaut?
Für Hintergrundinformationen zu Minimum CD und Antworten auf andere häufige Fragen, lesen Sie bitte die FAQs.
Die Reise beginnen
Haben Sie Fragen, wo Sie anfangen sollen? Sehen Sie sich einige Empfehlungen an.
Beitragen
Möchten Sie eine Übersetzung, Best Practices, Vorschläge oder einen Erfahrungsbericht einreichen?
Lesen Sie unsere Richtlinien für Beiträge