Continuous Deployment verstehen

Quality Gates

Um Änderungen ohne jede manuelle Steuerung freigeben zu können, müssen Sie volles Vertrauen in Ihren CI/CD-Prozess haben. Insbesondere müssen Sie sicherstellen, dass Ihr automatisierter Buildvorgang und Ihre automatisierten Tests Ihren Code effektiv prüfen. Bei diesem Schritt können Quality Gates für Ihren Code Unterstützung leisten.

Quality Gates legen fest, welche Kriterien der Code erfüllen muss, bevor er in die nächste Pipeline-Phase entlassen wird. Bei einigen Phasen können Sie einen einfachen Schwellenwert festlegen – z. B. 100% erfolgreiche Tests und 90% Code-Coverage durch Unit-Tests. Bei anderen automatisierten Tests kann es sinnvoll sein, einen bestimmten Prozentsatz an Warnungen zuzulassen, bei Fehlern jedoch abzubrechen. Manchmal werden auch Fehler oder Warnungen für eine manuelle Überprüfung vorgelegt, bevor der Schritt abgebrochen wird.

Automatisierte Quality Gates in den wichtigsten Phasen Ihrer Pipeline geben Ihnen Kontrolle, Einblicke in den Prozess sowie vollständige Prüfaufzeichnungen über die Erfüllung der Sorgfaltspflichten bei jedem Release.

Releasestrategie überlegen

Eine Schlüsselfrage bei der Planung Ihres Continuous-Deployment-Systems ist die Art und Weise, wie Ihre Änderungen in die Produktion übernommen werden sollen. Wenn Server für jedes Deployment offline gehen müssen, führt dies zu häufigen Unterbrechungen der Online-Verfügbarkeit, sodass eine rollierende Updatestrategie oft bevorzugt wird. Mit Canary-Deployments können Sie das Rollout auch zu einer Erweiterung Ihres automatisierten Testprozesses machen.

Canary-Deployments

Bei einem Canary-Deployment wird die Bereitstellung des aktualisierten Codes auf einen kleinen Anteil der User beschränkt, die auf diese Weise unwissentlich an Tests in der Produktionsumgebung teilnehmen. Durch Verhaltens- und Nutzungsüberwachung können Sie vor einem flächendeckenden Deployment sicherstellen, dass die neue Version keine neuen Fehler enthält.

Canary-Vertrauenswert

Einige Unternehmen gehen mit der Automatisierung noch einen Schritt weiter und nutzen einen sogenannten Canary-Konfidenzwert, der automatisch eine ganze Reihe von Kennzahlen mit Referenzwerten vergleicht. Der automatische Rollout wird nur fortgesetzt, wenn der Wert einen vorgegebenen Schwellenwert überschreitet. Wenn der Wert zu niedrig ist, bietet die Analyse einen Ausgangspunkt für die weitere Untersuchung möglicher Probleme.

Blue-Green-Deployments

Sogenannte „blaue“ und „grüne“ Builds werden oft von Unternehmen verwendet, die ein Continuous-Deployment-System einsetzen. Blue-Green-Deployments erleichtern das Rollback eines Releases im Falle eines Problems, da der alte Code online bleibt, bis Sie sicher sind, dass die Änderungen wie erwartet funktionieren. Bei Bedarf kann ein Blue-Green-Rollout auf ein erstes Canary Deployment folgen.

Überwachung von Produktionsstatistiken

Unabhängig davon, ob Sie ein Blue-Green-System verwenden oder direkte Rollouts durchführen, ist die Überwachung des Produktionssystems von entscheidender Bedeutung, um auf Fehler, die durch das Netz Ihrer automatisierten Tests schlüpfen, schnell reagieren zu können.

Identifizieren Sie als Erstes die zentralen Daten, die den Zustand Ihres Systems anzeigen. Dazu gehören Daten zum Systemzustand, wie z. B Festspeicher- und CPU-Nutzung, sowie Nutzungsstatistiken wie die Anzahl der Anfragen oder Transaktionen. Durch den Abgleich dieser Werte mit einer Basislinie können Sie früh erkennen, wenn sich die Dinge nicht so verhalten, wie sie sollten. Sie können dann entscheiden, ob Sie ein Rollback auf die Vorversion vornehmen oder lieber einen Fix über die Pipeline bereitstellen.

Stakeholder einbeziehen

Der Softwareentwicklungszyklus umfasst mehr als nur Codeänderungen. Die Teams für Benutzerforschung, Produktmarketing, Interaktionsdesign, Dokumentation, Vertrieb, Recht und Support spielen ebenfalls wichtige Rollen.

Wenn Sie nicht mit allen Beteiligten gemeinsam das Fundament legen und ihre jeweiligen Anforderungen an den Releaseprozess herausfinden, kann sich der Umstieg auf automatisierte Releases für die anderen Teams so anfühlen, als wären bei der Entwicklungsabteilung die Zügel gerissen. Das kann dazu führen, dass Stakeholder auf manuelle Checkpoints und Review-Phasen bestehen, was den Prozess verlangsamt und die Vorteile von CI/CD untergräbt. Im schlimmsten Fall kann es dazu kommen, dass das gesamte Continuous-Deployment-System als gescheitertes Experiment eingestampft wird.

Zusammenarbeit fördern

Damit Continuous Deployment gut funktioniert, ist eine Kultur der Zusammenarbeit unerlässlich. Die Einbeziehung anderer am Entwicklungsprozess beteiligter Teams, um ihre Inputs zu Design, Sicherheitsproblemen, Terminologie oder Compliance frühzeitig berücksichtigen zu können, ist ein Beispiel dafür, wie kurze Feedback-Schleifen den Softwareentwicklungszyklus effizienter machen.

Alle Beteiligten informieren

Genauso wichtig wie das Anfordern von Inputs ist die Transparenz darüber, was wann veröffentlicht wird. Halten Sie die Stakeholder mithilfe eines CI-Servers automatisch auf dem Laufenden. Je nachdem, für welches Continuous-Deployment-Tool Sie sich entscheiden, können Sie normalerweise Informationen über Dashboards und Benachrichtigungen weitergeben.

Feature-Flags oder speziellen Branch verwenden

Transparenz über kommende Releases ist jedoch manchmal nicht ausreichend. Wenn Sie an einem größeren Feature arbeiten oder das Timing der Releases steuern müssen, ist es nicht ideal, wenn jeder Commit nach Bestehen aller Tests einfach live geschaltet wird.

Feature-Flags sind eine Möglichkeit, die Sichtbarkeit von Code in der Produktion zu steuern. Der Vorteil ist, dass der Code live ist, sodass Sie Ihre Software auf unerwartete Fehler überwachen können.

Ein anderer Ansatz besteht darin, einen dedizierten Branch und eine separate Pipeline zu verwenden, die keine automatische Produktionsfreigabe umfasst. Dadurch können Sie Continuous Delivery und Continuous Deployment nach Ihren Bedürfnissen kombinieren.

Mehr darüber, wie Sie Ihren CI/CD-Prozess vereinfachen und bessere Ergebnisse erzielen können, erfahren Sie in unserem Leitfaden zu Best Practices für Continuous Deployment.

• Continuous Deployment ist eine DevOps-Methode, die alle Phasen des Build-, Test- und Releaseprozesses automatisiert.
• Das Ziel von Continuous Deployment besteht darin, den Benutzer*innen neue Funktionen schneller und häufiger bereitzustellen, ohne sich auf Qualitätskompromisse einzulassen.
• Continuous Deployment eignet sich besonders für Websites und Webanwendungen, da die Benutzer*innen die Updates nicht selbst anwenden müssen.
• Schnellere, häufigere Releases ermöglichen ein schnelles Benutzerfeedback und reduzieren die Auswirkungen von Fehlern, die sich in die Produktion einschleichen.
• Automatisierte Tests, Produktionsüberwachung, Zusammenarbeit mit anderen Abteilungen und Informationen über das Benutzerverhalten liefern allesamt Inputs für den Softwareentwicklungsprozess.
• Indem Sie Ihre Arbeit in kleinere Stücke aufteilen und häufige Releases veröffentlichen, können Sie auf Feedback reagieren und Ihr Produkt kontinuierlich verbessern.

TeamCity erleichtert die Einrichtung eines Continuous-Deployment-Systems mit hochgradig konfigurierbaren Trigger-Optionen und Deployment-Runnern. Dank dedizierter Deployment-Buildkonfigurationen können Sie die Berechtigung für Produktionsfreigaben einschränken, und durch flexible Build-Trigger lassen sich Freigabebedingungen definieren. Die in TeamCity integrierte Unterstützung für Paket-Repositories und Container-Registries hilft Ihnen, Ihre Build-Artefakte als Teil Ihres Continuous-Deployment-Prozesses zu verwalten.

Informieren Sie Ihre Stakeholder über alle Fortschritte, indem Sie ihnen Zugriff auf die intuitiven, webbasierten Dashboards von TeamCity geben. Dank einer leistungsstarken rollenbasierten Zugriffssteuerung können Sie den Weg in die Produktion absichern, und integrierte Audit-Trails stellen ein umfassendes Protokoll aller Aktivitäten in Ihren Pipelines bereit.