Am Freitagnachmittag verdienen sich Release-Manager ihren Kaffee. Die Build war erfolgreich, der Deploy-Job lief sauber ab und das Dashboard sagt, dass die neue Version live ist. Dann schickt der Support eine Benachrichtigung in den Kanal, weil die Benutzer immer noch die alte Funktionalität auf dem Mobilgerät sehen oder nur ein Teil der Benutzer den Änderungen unterzogen wurden, weil der tatsächliche Releasepfad hinter der App-Store-Überprüfung, Feature-Flags oder einer OTA-Kanal liegt, über den sich niemand außerhalb des Engineering-Teams bis es kaputt geht, Gedanken macht.
Das ist der ganze Story. Implementierung bewegt code, Veröffentlichung kontrolliert die Benutzerexposition und eine reife Veröffentlichungsverwaltung muss sowohl die Implementierung als auch die Veröffentlichung steuern. Die besten Modelle behandeln es als ein End-to-End-Kontrollsystem mit sechs Phasen, und sie messen die Gesundheit mit den vier DORA-Metriken, Implementierungs-Häufigkeit, Zeitaufwand für Änderungen, Fehlerquote bei Änderungen, und mittlere Zeit bis zur Wiederherstellung (MTTR)weil diese Zahlen Geschwindigkeit, Stabilität und Wiederherstellungszeit in einem Blick beschreiben (Arcad Software).
Inhaltsverzeichnis
- Warum die meisten Leitfäden zur Release-Verwaltung das Kernproblem übersehen
- Die sechs Phasen eines reifen Release-Lebenszyklus
- Die Messung der Release-Gesundheit mit DORA-Metriken
- Traditionelle gegen dezentrale Release-Verwaltung
- Best Practices für Branching, Gating und Rollbacks
- Release-Management für Capacitor und Electron-Apps mit OTA-Updates
- Erstellung eines Release-Readiness-Checklists für Ihr Team
Why die meisten Release-Management-Leitfäden die zentrale Problematik verpassen
Das klassische Versagensmuster zeigt sich am Freitag. Die Mannschaft fusioniert den code, die Buildpipeline verläuft erfolgreich, die Bereitstellung in die Produktion gelingt, und der Änderung erreichen die Benutzer auf keine bedeutende Weise. Bei Webanwendungen kann diese Verzögerung aus dem Cacheverhalten oder einer aufgeteilten Rollout-Phase resultieren. Bei mobilen Anwendungen kann es noch schlimmer sein, da die code erstellt wird, aber die Auslieferung noch auf die App-Store-Überprüfung oder eine OTA-Pfad wartet.
Die Bereitstellung ist nicht dasselbe wie der Release
Diese Unterscheidung ist wichtig, da viele Leitfäden den Release noch immer als wenn er an der Bereitstellungsschritt stattfindet, beschreiben. Moderne Release-Management-Verfahren behandeln die Bereitstellung als technische Bewegung von Artefakten, während der Release die Entscheidung darstellt, "wer was und wann sieht". Ein reifer Prozess verwendet Planung, Versionskontrolle, Validierung, kontrollierte Auslieferung und retrospektives Lernen, nicht nur "es wird verschifft und man hofft".Praktische Regel:
Wenn Ihre Mannschaft ohne Auswirkungen auf jeden Benutzer bereitstellen kann, haben Sie bereits Release-Kontrolle, ob Sie es so benennen oder nicht. Dies ist noch wichtiger bei
mobilen und hybriden Apps wobei die App-Store-Überprüfung den Release-Weg in eine Engstelle verwandelt und die Zeitlauffertigung zum Haupt-Kontrollschicht wird. Die praktische Frage ist nicht mehr "Ging die Build raus?" Es ist "Welche Benutzer sehen die Änderung, können wir den Effekt überprüfen und können wir die Auslieferung ohne einen vollständigen Neudeploy stoppen?"mobile and hybrid apps
Auflistung der Entscheidungen ist ein nützliches mentales Modell. Planung definiert den Umfang und das Risiko, Build und Versionsverwaltung erstellen ein kontrolliertes Artefakt, Testen beweist, dass das Artefakt akzeptabel ist, die endgültige Validierung entscheidet, ob es sicher ist, das Artefakt auszuliefern, die Bereitstellung bringt es in die Zielumgebung und die Nachveröffentlichungsanalyse überprüft, ob die Realität dem Plan entspricht. Diese Struktur ist nicht nur Bürokratie für ihre eigene Sake. Es ist die Art, wie Teams kleine Fehler verhindern, dass sie in weitverbreitete Vorfälle umschlagen.
Wenn Teams dieses Modell überspringen, werden sie normalerweise nicht schneller. Sie verschieben nur das Risiko nach unten, wo es schwieriger zu diagnostizieren und teurer zu bereinigen ist.
Für mobile Teams ist die Trennung zwischen Bereitstellung und Auslieferung keine Theorie. Sie ändert die Kontrollpunkte. Ein Build kann in einer Warteschlange sitzen, während ein OTA-Kanal es ermöglicht, den Ausbreitungsradius zu begrenzen, eine Reparatur mit einer kleineren Zielgruppe zu testen oder eine Rollout zu pausieren, wenn die Metriken zu schweben beginnen. Deshalb muss das Release-Management-Prozess sowohl die Bewegung des Artefakts als auch die Benutzerfreundliche Änderung verfolgen. Das Artefakt mag existieren, aber die Veröffentlichung ist nicht abgeschlossen, bis die richtigen Benutzer es über den von Ihnen kontrollierten Kanal erhalten, einschließlich der Übersicht über die Build-Typen die bestimmen, wie diese Artefakte durch den Pipeline bewegt werden.
Die sechs Phasen eines ausgereiften Release-Lifecycle
Aufrechtephasen in einem Releaselifecycle sind einfacher zu verwalten, wenn jeder Schritt ein klares Entscheidungspunkt hat. Der Punkt ist nicht darin, den Prozess schwerer zu machen. Der Punkt ist darin, das Scheitern früher sichtbar zu machen, wenn der Auswirkungsbereich noch klein ist.
Planung und Aufbau arbeiten als Kontrollsystem
Die Planung beginnt mit Umfangsbegrenzung, Risikobewertungund Stakeholderausrichtung. Das klingt routinemäßig, aber es ist dort, wo sich Teams entscheiden, ob eine Änderung in einem Standardrelease, einem Notfallpfad oder einem längeren Stabilisierungszyklus gehört.
Je besser die Planungsdisziplin, desto weniger Überraschungen zeigen sich während der Validierung. capgo.app article on build types is useful context for thinking about how different artifacts move through release pipelines, especially when you’re separating code packaging from user exposure (Der).
Artikel zu Build-Typen ist ein nützliches Kontext, um darüber nachzudenken, wie unterschiedliche Artefakte durch Releasepipelines bewegt werden, insbesondere wenn man sich von __CAPGO_KEEP_0__-Packaging trennt (
Testen, Validierung, Bereitstellung und Lernen. Testen und QA sollten mehr tun als nur bestätigen, dass etwas läuft. Sie müssen Regressionspfade, Leistungserwartungen und offensichtliche Bruchstellen überprüfen, bevor sich die Änderung den Benutzern nähert. Die endgültige Validierung ist der Go- oder No-Go-Punkt, an dem sich die Änderungsbewilligung, die Rollback-Prozeduren und die Zustimmung zusammenfinden. Wenn das Team die Rollback-Route nicht in einfachen Worten beschreiben kann, ist die Release nicht bereit.
Die Produktionsbereitstellung sollte progressive Offenlegung unterstützen. Kanarische Muster, Feature-Flags und schrittweise Bereitstellungen reduzieren die Wahrscheinlichkeit, dass ein schlechteres Änderungsbefehl alle gleichzeitig trifft.
Das unten stehende Modell ist ein gutes Beispiel dafür, dass Reife durch Kontrolle, nicht durch Zeremonie gemessen wird.
Die Übergehung einer Phase rettet selten Zeit. Es bedeutet meistens, dass der Fehler später eintritt, nachdem mehr Menschen auf die Veröffentlichung angewiesen sind und die Rückschaltzeit sich verringert hat.
Die Messung der Release-Gesundheit mit DORA-Metriken
Die Zählung von Veröffentlichungen ist ein schwacher Weg, um die Qualität der Veröffentlichung zu beurteilen. Ein Team kann oft veröffentlichen und trotzdem ungeschickt, riskant und schwer zu rekonstruieren sein. Die vier DORA-Metriken beschreiben die Liefergeschwindigkeit und -stabilität besser, als nur die Anzahl der code-Veränderungen zu zählen.
Was jede Metrik sagt
Die Frequenz der Bereitstellung sagt dir, wie oft der Pipeline echte Änderungen für die Benutzer produziert. In der Praxis spiegelt sie die Disziplin der Batchgröße wider. Wenn Veröffentlichungen selten sind, sind Teams wahrscheinlich zu viel Arbeit gebündelt, warten zu lange auf die Genehmigung oder tragen zu viel Angst in den Prozess ein.
Die Zeit bis zur Änderung zeigt, wie lange eine Änderung wartet, bevor sie in die Produktion kommt. Elite-Teams setzen nach Bedarf und halten die Zeit für Änderungen unter eine Stunde (UnleashDieser Schwellenwert ist wichtig, weil ein kurzer Weg von der Commit- zu der Produktionsumgebung Kontextverlust reduziert und das Debuggen erheblich erleichtert.
Änderungsfehlerrate zeigt Ihnen, wie oft Releases die Dienstleistung verschlechtern. Das Elite-Benchmark liegt typischerweise 0 bis 15%. Diese Zahl ist kein Trophäe, sondern ein Hinweis darauf, dass das Team die richtigen Dinge testet und den Auswirkungsbereich klein hält.
MTTR zeigt, wie schnell der Dienst nach einem Vorfall wiederhergestellt wird. Elite-Teams können sich schnell erholen weniger als eine Stunde. Das ist wichtig, weil eine starke Rollback-Pfad und eine gute Beobachtung oft wertvoller sind als Heroismus während eines Ausfalls.
Praktische Regel: Die Rollback-Frequenz und die post-release-Incidenten sollten zusammen mit den DORA-Metriken verfolgt werden, weil ein 'erfolgreicher Deploy' , der später zu Incident-Churn führt, immer noch ein schwacher Release ist.
Instrumentierung schlägt Speicher
Die stärksten Teams integrieren die Metrik-Erfassung in den Pipeline, so dass die Daten automatisch ankommen und nicht durch manuell eingegebene Berichte.
Traditionelle Ausgabetracking endet bei 'hat es deployt.' Das verpasst die wichtigste Frage, nämlich, ob der Release sicher, sichtbar und wertvoll war. Für Teams, die einen operativen Blick auf die Laufzeitgesundheit und die Erkennung wollen, ist das Anwendungs-Überwachung Die Anleitung von Capgo ist ein nützlicher Begleiter.
Ein Release-Prozess, der die Wiederherstellung nicht messen kann, ist nur halb gebaut. Geschwindigkeit ohne Wiederherstellungsdisciplin macht nur die Ausfälle schneller.
Traditionelles vs. Entkoppeltes Release-Management
Traditionelles Release-Management geht davon aus, dass die Bereitstellung und die Benutzerexposition zusammen passieren. Das funktionierte, als der Release ein einzelnes Ereignis war und der Serverzustand dasselbe war wie die Benutzererfahrung. Es bricht jedoch schnell zusammen, wenn man Feature-Flags, staged Rollouts und mobile Verteilungsbeschränkungen einführt.
Lineares Release-Flow gegenüber Laufzeit-Kontrolle
Das alte Muster ist einfach. Planen, bauen, testen, bereitstellen, und dann lässt man allen die Änderung sehen. Der Vorteil ist die Klarheit. Der Nachteil ist, dass ein schlechter Push den ganzen Publikum beeinflussen kann, und ein Rollback bedeutet oft einen anderen Neubereitstellung.
Entkopplte Release-Management trennt die Handlung des Versands von code von der Handlung der Offenlegung. Das gibt Teams eine sichere Kontrollfläche. Man kann code stilllegen, es einer kleinen Gruppe von Benutzern zugänglich machen, den Einfluss überprüfen und dann den Rollout erweitern. Die Bereitstellung ist technisch. Die Freigabe ist eine Produktentscheidung.
Der unten stehende Vergleich fasst den Wechsel von der Batch-Style-Bereitstellung zur Laufzeit-Kontrolle zusammen.
Wo jedes Modell noch passt
Traditionelles Batching hat noch einen Platz. Regulierte Branchen, große Versionswechsel und große koordinierte Starts benötigen stärkere Änderungskontrolle und explizite Genehmigungen. Der Prozess ist langsamer, aber der Koordinationskosten sind akzeptabel, wenn Compliance oder Geschäftsrisiko hoch ist.
Decoupled Lieferung gewinnt, wenn Teams schnell iterieren, sicherer experimentieren oder mobile Steuerungspfade benötigen, die nicht von jedem Benutzer abhängen, der dieselbe Binärdatei zur gleichen Zeit erhält. Das ist das kritische Problem in hybriden und mobilen Apps, wo die Auslieferung bei Laufzeit und die Richtliniengate oft wichtiger sind als die Veröffentlichung im Store selbst. Die praktische Frage wird, wie man Änderungen an bestimmten Benutzern offenlegt, das Verhalten überprüft und die Offenlegung rückgängig macht, ohne auf eine neue Store-Zyklus wartet.
Für eine tiefergehende Vergleichbarkeit von store-bundenen Updates und direkten Update-Kanälen ist diese Übersicht im Moment wertvoll, wenn Ihr Team entscheidet, wie viel Freigabe-Kontrolle im App gegenüber der Plattform (App-Store vs. direkte Updates) leben sollte.App-Store vs. direkte Updates).
Best Practices für Branching, Gating und Rollbacks
Die Kontrollen, die die Veröffentlichungen sicher halten, sind normalerweise langweilig, wenn sie funktionieren und schmerzhaft erinnerlich, wenn sie nicht funktionieren. Eine gute Branching-, Gating- und Rollback-Design gibt Ihnen genug Struktur, um schnell voranzukommen, ohne dass jede Änderung zu einem Feuerwehr-Training wird.
Branching sollte der Größe der Änderung entsprechen
Trunk-based Development passt sich der kontinuierlichen Lieferung an, weil sie die Integration häufig hält und die Abdrift vermeidet, die von lang lebenden Branches kommt. Feature-Branches stellen immer noch Sinn für größere Änderungen, die Isolation benötigen, aber sie sollten kurzlebig und aktiv integriert werden. Release-Branches sind nützlich, wenn ein Team Stabilisierung benötigt, ohne die Hauptlinienerarbeit einzustellen.
The Fehler liegt in der Verwendung der Zweigstrategie als Komfortsänfte. Ein langer Zweig kann die Integrationsschmerzen bis zum Ende verbergen, wo es teuer wird. Kurzere Wege machen Merge-Konflikte früher sichtbar und machen die Freigabenisiko einfacher zu erkennen.
Gates sollten den schlechten Wechsel vor den Benutzern stoppen
Automatisierte Qualitätsprüfungen müssen die Probleme unter Druck erkennen, die Menschen verpassen. Das bedeutet, dass Test-Suiten, Sicherheits-Scans und Leistungsbaselines vor der Produktionsexposition laufen müssen. Die manuelle Genehmigung ist für hohe Risikovorlagen immer noch wichtig, aber sie sollte auf der Maschinenvalidierung liegen, nicht sie ersetzen.
Eine nützliche Steuerungsmuster ist die Trennung von Standardfreigaben von Notfallfreigaben. Notfalländerungen benötigen schnellere Governance-Wege, aber sie benötigen immer noch Nachverfolgbarkeit. Ein ausgereiftes Freigabesystem kann sagen, wer die Änderung genehmigt hat, von welchem Basispunkt sie kam und welche Rollover-Option verfügbar war, wenn die Freigabe defekt war.
Rollover-Pläne scheitern am meisten, weil sie als Papierkram behandelt werden. Blaue-grüne Bereitstellungen, umkehrbare Datenbankänderungen und Feature-Flag-Schaltflächen sind alle stärker, wenn sie unter Druck geübt wurden. Wenn das Team nie den Rollover-Weg getestet hat, ist es nur eine Theorie, nicht eine Fähigkeit.
Das zugrunde liegende Kontrollmodell wird gut in der Rollover-Strategie-Richtlinie für CI/CD-Workflows erfasst, was es wert ist, wenn Ihr Team die Wiederherstellungsverfahren ("rollback strategies for CI/CD workflows") verschärft.
Die Fehler sind in der Verwendung der Zweigstrategie als Komfortsänfte zu finden. Ein langer Zweig kann die Integrationsschmerzen bis zum Ende verbergen, wo es teuer wird. Kurzere Wege machen Merge-Konflikte früher sichtbar und machen die Freigabenisiko einfacher zu erkennen.Gates sollten den schlechten Wechsel vor den Benutzern stoppen. Automatisierte Qualitätsprüfungen müssen die Probleme unter Druck erkennen, die Menschen verpassen. Das bedeutet, dass Test-Suiten, Sicherheits-Scans und Leistungsbaselines vor der Produktionsexposition laufen müssen. Die manuelle Genehmigung ist für hohe Risikovorlagen immer noch wichtig, aber sie sollte auf der Maschinenvalidierung liegen, nicht sie ersetzen. Eine nützliche Steuerungsmuster ist die Trennung von Standardfreigaben von Notfallfreigaben. Notfalländerungen benötigen schnellere Governance-Wege, aber sie benötigen immer noch Nachverfolgbarkeit. Ein ausgereiftes Freigabesystem kann sagen, wer die Änderung genehmigt hat, von welchem Basispunkt sie kam und welche Rollover-Option verfügbar war, wenn die Freigabe defekt war. Rollover-Pläne scheitern am meisten, weil sie als Papierkram behandelt werden. Blaue-grüne Bereitstellungen, umkehrbare Datenbankänderungen und Feature-Flag-Schaltflächen sind alle stärker, wenn sie unter Druck geübt wurden. Wenn das Team nie den Rollover-Weg getestet hat, ist es nur eine Theorie, nicht eine Fähigkeit. Das zugrunde liegende Kontrollmodell wird gut in der Rollover-Strategie-Richtlinie für CI/CD-Workflows erfasst, was es wert ist, wenn Ihr Team die Wiederherstellungsverfahren verschärft.).
Praktische Regel: Wenn ein Rollback eine Besprechung erfordert, ist der Rollback zu langsam.
Veröffentlichungsverwaltung für Capacitor- und Electron-Apps mit OTA-Updates
Das erste Mal, wenn ein hybrider App-Team durch die Store-Latenz gebrannt wird, bleibt der Lernprozess. Ein JavaScript-Fix ist bereit, die native Schale ist in Ordnung, und der Fehler ist offensichtlich im gelieferten Bundle. Das Problem ist, dass der App-Store nun Teil des Veröffentlichungspfads ist, sodass das Team den code nicht gleich am Nachmittag beheben und pushen kann.
Dort, wo OTA-Kontrollen das Spiel ändern. In Capacitor- und Electron-Workflows können Teams JavaScript, CSS, Kopien, Konfigurationen und Asset- Fixes ohne Wartezeit für einen vollständigen App-Store-Zyklus versenden. Capgo ist eine Option in dieser Kategorie, es bietet live-Updates, kanalbasierte Veröffentlichungen, Rollback-Unterstützung und differenzielle Updates für CapacitorJS- und Electron-Apps. Sein Veröffentlichungsfluss ist um signed Bundles, zielgerichtete Kanäle und Beobachtbarkeit auf Geräteebene herumgebaut, was die Veröffentlichungsentscheidung viel näher an der Ausführung als an der Binärdatei bringt.
Welche Änderungen treten auf, wenn die Ausführung angetrieben wird
Sobald die Bereitstellung von der Benutzerfreigabe getrennt ist, wird die Release-Verwaltung zu einem Problem der Richtlinie genauso wie zu einem Versandproblem. Ein Beta-Kanal kann das Bundle zuerst erhalten, eine Testgruppe kann die Aktualisierung validieren und eine kundenbezogene Strömung kann die Reparatur ohne Berührung der anderen erhalten. Diese Struktur funktioniert, weil das Team kontrollieren kann, wer die Aktualisierung sieht, nicht nur, ob das Bundle existiert.
Differential-Updates sind wichtig, weil sie die Menge an Daten reduzieren, die gesendet werden, wenn nur ein Teil des Bundles geändert ist. Das ist ein praktischer Anpassung für mobile Benutzer auf eingeschränkten Netzwerken und für häufige Patch-Zyklen, bei denen der Payload hauptsächlich unverändert ist. Signierte Web-Bundles sind wichtig aus dem gleichen Grund, aus dem Server-Seitensignaturen überall sonst wichtig sind, sie halten den Update-Weg kontrolliert.
Wie sieht ein gutes OTA-Disciplin aus
Der operative Vorteil liegt in der Rückgängigmachungsschutz. Wenn ein schlechtes Bundle zu Crashes oder gebrochenen UI-Flüssen führt, kann das System die Exposition unterdrücken oder ersetzen, ohne eine neue Store-Veröffentlichung. Der Support kann die Geräteprotokolle und die Versionsgeschichte ansehen, während das Engineering die Adoption und die Fehlermuster durch den Kanal überprüft, anstatt zu raten, basierend auf Anekdoten.
Der andere Disziplinpunkt ist die Kanal-Grenzen. Teams benötigen starke Regeln, damit ein Testbau nicht in die Produktion gelangt. CI/CD-Integrationen helfen hier, weil der Pipeline die Bundles in die richtige Strömung hochladen kann, anstatt auf einen manuellen Operator zu vertrauen, der unter Druck die richtige Zielgruppe wählt.
Für Implementierungsdetails zu der Automatisierung dieses Flusses, ist die Capgo-Anleitung zur CI/CD-Integration die relevanteste Referenz, die in der Nähe bleiben sollte (Capgo-Anleitung zur CI/CD-Integration für OTA-Updates).
Erstellung eines Release-Readyness-Checklists für Ihr Team
Ein guter Release-Checklist ist kein Papierkrieg. Es ist der minimale Satz von Kontrollen, der das Team von der Entdeckung grundlegender Fehler nach der Benutzerfreigabe abhält. Die stärksten Checklisten kombinieren die Pipeline-Automatisierung, die Sicherheitskontrollen, die Compliance-Abstimmung und die Beobachtbarkeit in einem Routine.
Vorfreigabekontrollen, die wirklich zählen
Beginnen Sie mit der Integrität der Artefakte. Signierte Builds, Zugriffssteuerungen und geheime Handhabungen sollten vor der Freigabe überprüft werden, bevor die Freigabe weitergeht. Dann überprüfen Sie den Freigabespezifischen Genehmigungsverlauf, insbesondere wenn Ihr Team in der Finanzwirtschaft, im Gesundheitswesen oder in jedem anderen Umfeld arbeitet, in dem die Änderungsgeschichte relevant ist.
Beobachtbarkeit gehört in den Checklist, nicht in die Nachberechnung. Die Freigabe sollte ein klares Überwachungsplan haben, definierte Warnschwellen und ausreichendes Tracing, um die erste fehlende Abhängigkeit isolieren zu können. Wenn das Team nicht erklären kann, was nach der Freigabe überwacht werden soll, ist es nicht bereit, die Freigabe durchzuführen.
Ein einfacher Betriebschecklist
- Artefaktbereitschaft: Bestätigen Sie, dass das Bundle oder die Binärdatei signiert, versioniert und auf ein kontrolliertes Basisniveau zurückverfolgbar ist.
- Genehmigungsverlauf: Überprüfen Sie, wer Standard-, Notfall- und Hochrisikofreigaben genehmigen kann.
- Rücksetzpfad: Bestätigen Sie die Rücksetzmethodik, den Besitzer und die erwartete Wiederherstellungssequenz.
- Überwachungskonfiguration: Stellen Sie sicher, dass die Protokollierung, die Anomaliedetektion und die Alarmrouten vor der Freigabe aktiv sind.
- Audit-Trail: Halten Sie die Release-Protokolle vollständig für die Compliance-Überprüfung und die Analyse von Vorfällen.
Das Release-Management-Verfahren wird besser, wenn diese Liste als lebendige Steuerfläche und nicht als statisches Dokument behandelt wird. Jedes Vorkommnis, jeder nahe Miss und jede glatte Freigabe sollte die Liste ein bisschen ändern. So wenden sich Teams das Release-Management in die kontinuierliche Überprüfung und nicht in ein wiederholtes Glücksspiel um.
Wenn Ihr Team versucht, die Release-Zyklen zu verkürzen, ohne die Kontrolle zu verlieren, bietet Ihnen Capgo einen praktischen Weg, um OTA-Updates zu versenden, Kanäle zu verwalten und schlechte Pakete ohne Wartezeit auf die App-Store-Überprüfung zurückzusetzen. Besuchen Sie Capgo um zu sehen, wie sich der Update-Flow von Capacitor und Electron in realen Pipelines mit dem Release-Management vereinbaren lässt.
