Menü

Release Management in DevOps

release management devops

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Was ist Release Management in DevOps?

Ich hoffe, Ihnen wäre klar gewesen Konfigurationsmanagementkonzept in DevOps aus unserem letzten Tutorial.

Wie wir zuvor DevOps definiert haben, ist DevOps das gesamte Team, das die Software von Anfang an bis zur Auslieferung an die Produktion besitzt und sicherstellt, dass die Anwendung in der Produktion gemäß den Anforderungen ausgeführt wird.

Empfohlene Lektüre => Die besten DevOps-Schulungsanleitungen aller Zeiten

Release Management in DevOps

Wie wir alle wissen, besteht das „Release Management“ darin, zu verwalten, welche Version der Software in welcher Umgebung wann und wie bereitgestellt wird. Dies liegt nicht nur in der Verantwortung des Release Managers, sondern in der Verantwortung des gesamten Teams in DevOps.

Die Hauptvorteile von Release Management in DevOps lassen sich wie folgt zusammenfassen:

    • Schnellere und konsistentere Lieferungen.
    • Starke Prüfung und Rückverfolgbarkeit von Änderungen.
    • Automatisierung des Freigabeprozesses: Höhere Qualität, Konsistenz, Vertrauen.
    • Steigert das Vertrauen durch erfolgreiche und konsistente Lieferungen.
    • Befreiung machen - ungestresste Aktivität
    • Keine Ausfallzeiten

VIDEO Part4 Block 2: Release Management- 17 Minuten 12 Sekunden

Transkript:

In diesem Block werden wir das verstehen Release-Management-Verfahren von DevOps .

Was ist Release Management im DevOps-Kontext und was sind seine Hauptvorteile?

Wenn ich an das Release-Management denke, stellen sich mir verschiedene Fragen: Welches Release wird in welcher Umgebung ausgeführt und welche Patches wurden dort angewendet? Welche Hotfixes wurden bereitgestellt und für welchen Kunden?

Ich weiß, es ist das Problem des Release-Managers, all diese Informationen im Auge zu behalten. Wir wissen, dass das Release-Management früher weder in der Verantwortung des Entwicklers noch der Ops lag. Es war ein separates Release-Management-Team, das die Software-Release-Aktivitäten verwaltete.

Und ein separates Board namens CCB und CAB, Change Control Board, Change Approval Board, das die Verantwortung für die Verwaltung der Änderungen und die Kontrolle darüber übernimmt, was angewendet wird und was nicht.

Aber jetzt haben sich die Dinge mit den DevOps geändert. Und es liegt nicht mehr nur in der Verantwortung des Release Managers, sondern des gesamten Teams.

Wie wir DevOps bereits definiert haben, ist DevOps ein ganzes Team, das die Software von Anfang an bis zur Auslieferung an die Produktion besitzt und sicherstellt, dass die Anwendung in der Produktion gemäß den Anforderungen ausgeführt wird.

Daher ist in DevOps die Softwareentwicklungsaufgabe nicht abgeschlossen, es sei denn, der Code wird auf der Site bereitgestellt und über einen bestimmten Zeitraum erfolgreich auf seine Leistung überwacht.

Daher liegt die Verantwortung für die Softwarebereitstellung und deren Leistung im Live-Modus bei jedem im Team. Dies gilt auch für die Release-Management-Aufgaben.

Wir werden mehr über Release-Management-Aspekte in DevOps erfahren.

Lassen Sie uns verstehen, was Release Management ist.

Wie wir alle wissen, verwaltet und verwaltet das Release-Management aus einer breiten Perspektive die Informationen, z. B. welche Version der Software oder der Komponenten in welchen Umgebungen wann und wie bereitgestellt wird.

SQL Fragen und Antworten für erfahrene

Hier dreht sich alles um das Release-Management.

Lassen Sie uns sehen, wie der Release Management-Prozess funktioniert.

Im Gegensatz zu früher gibt es in DevOps keine formellen CCBs. Dies bedeutet jedoch nicht, dass keine Genehmigungen für die Änderungen vorgenommen wurden.

Genehmigungen erfolgen auch über ein Tool. Die Änderungsmanagement-Tools wie Jeera und ClearQuest werden verwendet, um Änderungen aufzuzeichnen, zu genehmigen und an das Entwicklerteam weiterzuleiten, um einen Rückstand als technische Schuld oder neue Anforderung aufzubauen.

Diese vom Programmteam erfassten Änderungen werden erstellt, getestet und zusammen mit der automatisierten Lieferpipeline automatisch in der Produktion bereitgestellt. Jede Änderung wird jedoch in der Versionskontrolle protokolliert und diese Änderungen werden in der gesamten Lieferpipeline geprüft und getestet.

Unabhängig davon, welche Änderungen vom Team vorgenommen werden, werden diese im Versionskontrolltool aufgezeichnet, und was erfolgreich in den Umgebungen bereitgestellt wurde, und ihre Konfigurationen sind im Konfigurationstool verfügbar.

Daher geben sowohl die Versionskontrolle als auch das Konfigurationsmanagement zusammen ein klares Bild davon, was veröffentlicht wird, wann es veröffentlicht wird, wo es veröffentlicht wird und wie es veröffentlicht wird.

Im Kontext von DevOps fungieren also im Grunde die Versionskontrolle und das Konfigurationsmanagement als Release-Management-Tool. Diese beiden Prozesse und Tools fungieren also als CCB, die wir in unserer traditionellen Entwicklungsmethode nennen.

Grundsätzlich automatisiert es die Arbeit eines CCB-Managers, der im Idealfall jede dieser Änderungen oder Freigaben überprüft und zertifiziert, damit sie in die Produktion gehen können.

Im Fall von DevOps wird nicht die Version zertifiziert, sondern die gesamte Lieferpipeline wird zusammen mit manuellen Gates automatisiert zertifiziert.

Daher ist das Release-Management keine separate Aktivität als Teil von DevOps, sondern bereits als Teil der DevOps-Pipeline oder der Delivery-Pipeline zusammen mit der Versionskontrolle, dem Konfigurationsmanagement und der Bereitstellungspipeline integriert.

Die Versionskontrolle in Verbindung mit dem Konfigurationsmanagement übernimmt also das Release-Management.

Und während wir uns der DevOps-Praxis zuwenden, in der wir Lieferungen über einen Zeitraum von wenigen Stunden durchführen möchten, ist es praktisch unmöglich, solche häufigen Bereitstellungen sowie deren Aufzeichnung und Wartung manuell durch die herkömmlichen Release-Management-Prozesse zu verwalten, bei denen sie manuell mit Automatisierung verwaltet werden in sehr geringem Maße.

Eine vollständige Automatisierung des Release-Management-Prozesses ist daher ein Muss.

Außerdem müssen wir in der DevOps-Pipeline die Bereitstellungen nicht steuern. Wenn die Änderungen genehmigt, erstellt, getestet und in die Versionskontrolle übernommen werden, werden sie automatisch auf die Produktion angewendet. Natürlich gibt es Feature-Toggles zum Ein- und Ausschalten, um sie in der Produktion zu steuern.

Die Prüfung und Rückverfolgbarkeit jeder Änderung ist einer der größten Vorteile, die wir aus Sicht des Release-Managements haben. Wenn wir also die DevOps-Pipeline oder die Bereitstellungspipeline erstellen, bauen wir diese Protokollierung und Überwachung in die Pipeline ein, damit die Echtzeitereignisse in der Umgebung aufgezeichnet und überwacht werden.

Wir werden also die tatsächlichen Ereignisse ermitteln, die sich aus der Bereitstellung der Anwendung in der Umgebung ergeben. Da es sich um eine kürzere und kleinere Version handelt, ist es recht einfach, diese Änderungen in der gesamten Pipeline zu verfolgen.

Wir sind zum Tools-Teil des Release-Managements gekommen.

Auf dem Markt verfügbare Release-Management-Tools stellen sicher, dass die automatische Bereitstellung von Änderungen zeitnah und fehlerfrei erfolgt, und zielen darauf ab, den Benutzern den größtmöglichen Nutzen zu bieten.

Grundsätzlich handelt es sich um die Bereitstellungstools, die während der automatisierten Bereitstellung in der Bereitstellungspipeline verwendet werden.

XL Release ist ein solches Release-Management-Tool, das speziell für die kontinuierliche Bereitstellung entwickelt wurde. Wie bereits erwähnt, helfen diese Tools den DevOps-Teams beim Entwerfen ihres Bereitstellungsmodells und beim Überwachen der Releases, indem sie alle mit der Bereitstellung verbundenen Aufgaben automatisieren und die Releases verwalten.

Plutora ist ein weiteres derart robustes Tool, das ein On-Demand-Toolset für Enterprise IT Release Management-Software bereitstellt, das bei der Bereitstellung der Releases hilft.

Das Release Lifecycle Management-Produkt von BMC Software ist auch ein Release Management-Tool von BMC Software, das eine umfassende Übersicht über den Fortschritt des Software Releases bietet. Über ein zentrales webbasiertes Portal können Benutzer die Anwendungsentwicklung, Qualitätssicherung und Produktion verfolgen, um die Auswirkungen jeder vorgenommenen Änderung zu überwachen.

Es gibt noch ein anderes Tool von XebiaLabs. Mit diesem Tool können Sie die Pipeline für ihre Softwareversionen planen, automatisieren und analysieren.

Lassen Sie uns die Vorteile des automatisierten Release-Management-Systems von DevOps auflisten.

Erstens hilft der gesamte Release-Management-Prozess, der automatisiert wird, dem Team, schnellere und konsistentere Lieferungen an die Kunden zu erhalten.

Wir haben erfahren, dass jedes Mal, wenn eine Freigabe oder Änderung durch eine kontinuierliche Bereitstellungspipeline in der DevOps-Umgebung übertragen wird, alle Informationen darüber, was tatsächlich in der Umgebung passiert ist, klar in die Protokolle geschrieben werden.

Wir haben also tatsächliche Dinge oder Ereignisse in Echtzeit, die in das Protokoll geschrieben werden, ab dem, was während der tatsächlichen Bereitstellung der Version in einer bestimmten Umgebung passiert ist.

Damit haben wir eine sehr, sehr starke Prüfung und Rückverfolgbarkeit von Änderungen, die in DevOps beibehalten werden.

Jeder, der Änderungen an einem Teil der Lieferpipeline vornimmt, wird jederzeit nachverfolgt.

Wir werden in der Versionskontrolle haben, was geändert wurde, was bereitgestellt wurde und seine jeweiligen Konfigurationen. Auf diese Weise erhalten Sie einen klaren Überblick über die Details darüber, was geliefert wurde, wohin es geliefert wurde, wann und wie bei jeder Veröffentlichung.

Die Automatisierung der Release-Pipeline ist eine weitere großartige Funktion von DevOps, die manuelle Eingriffe so weit wie möglich verhindert und bei Versionsfehlern sehr einfach zurückverfolgt werden kann, indem die fehlgeschlagene Version mit der erfolgreichen Version verglichen wird.

Die Automatisierung der Release-Pipeline bietet uns also eine höhere Lieferqualität innerhalb von Minuten. Menschliche Fehler, Beständigkeit und offensichtlich größeres Vertrauen in die Lieferungen werden gemacht.

Auf diese Weise kann das Team die Bereitstellung oder Freigabe für die Produktion als Routine oder täglichen Zeitplan wahrnehmen, indem es die Freigabepipeline und ihre Bereitstellungen gründlich versteht.

Kein Zweifel, dass dieser Komfort und diese Zeitersparnis es den Menschen ermöglichen, sich mehr auf die anderen wichtigen Dinge als auf die Routine zu konzentrieren.

Wir wissen früher, dass Veröffentlichungen früher nach Stunden oder in den frühen Morgenstunden und im Allgemeinen an Wochenenden stattfanden. Und das Team musste diese Veröffentlichungen zu diesen Zeiten unterstützen.

Denken Sie an all die stressigen Momente vor der Freilassung, die nach Stunden oder am frühen Morgen wach sein würden, um den Einsatz durchzuführen, menschliche Fehler zu begehen, zu vergessen, eine Änderung vorzunehmen, und dann Gott zu beten, um die Freilassung erfolgreich zu machen und so weiter.

Die derzeitige DevOps-Methode für die Bereitstellung und das Release-Management hat all unseren früheren Problemen mit stressigen Momenten einen Vorhang gegeben.

c ++ Baumdatenstruktur

Keine Wochenendeinsätze mehr, keine schlaflosen Nächte mehr und kein Einsatzstress mehr. Alles ist automatisiert. Das Freigeben neuer Funktionen oder das Aktualisieren von Änderungen ist also keine stressige Aktivität mehr.

Die DevOps-Bereitstellungsmethode beinhaltet keine Ausfallzeiten oder Unterbrechungen für die Benutzer im Gegensatz zu dem früheren Fall, dass störende Ausfallzeitnachrichten an alle Kunden gesendet und diese aufgefordert werden, den Dienst nicht mehr zu nutzen, oder dass sie plötzlich mit den unerwarteten Problemen überrascht werden während des Upgrades und weitere Verlängerung der Ausfallzeit.

Lächerlich !! Warum sollten sie sich über die von uns durchgeführten Software-Upgrades Gedanken machen oder warum sollten sie Probleme mit diesen Updates haben?

Stören Sie die Benutzer nicht mit Aktualisierungen, die das Softwareteam am Server vornimmt. Daher hat DevOps 'Art, Veröffentlichungen zu machen, all diesen Problemen ein Ende gesetzt.

Keine Bereitstellungen über Nacht mehr, keine Patches mehr für die Kunden und kein Serviceausfall mehr.

Damit schließen wir das Thema „Release Management in DevOps“ ab.

In unserem kommenden Tutorial werden wir mehr über die erfahren Prozess zur Überwachung der Anwendungsleistung in DevOps.

PREV Tutorial | NÄCHSTES Tutorial

Literatur-Empfehlungen

^