Menu

Releasebeheer in DevOps

release management devops

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is releasebeheer in DevOps?

Ik hoop dat je er duidelijk over was geweest Configuratiebeheerconcept in DevOps van onze laatste tutorial.

Zoals we eerder DevOps hebben gedefinieerd, is DevOps het hele team dat eigenaar is van de software vanaf het begin totdat deze wordt geleverd aan de productie en ervoor zorgt dat de applicatie presteert in de productie volgens de vereisten.

Aanbevolen literatuur => Beste DevOps-trainingshandleidingen ooit

Releasebeheer in DevOps

Daarom is ‘Release Management’, zoals we allemaal weten, het beheren van welke versie van de software in welke omgeving, wanneer en hoe wordt geïmplementeerd, niet alleen de verantwoordelijkheid van de Release Manager, maar de verantwoordelijkheid van het hele team in DevOps.

De belangrijkste voordelen van Release Management in DevOps kunnen worden samengevat als:

    • Snellere en consistente leveringen.
    • Sterke audits en traceerbaarheid van wijzigingen.
    • Automatisering van het releaseproces: hogere kwaliteit, consistentie, vertrouwen.
    • Verhoogt het vertrouwen door succesvolle en consistente leveringen.
    • Loslaten - niet-gespannen activiteit
    • Geen downtime

VIDEO Deel 4 Blok 2: Releasebeheer- 17 minuten 12 seconden

Vertaling:

In dit blok zullen we de Release Management procedure van DevOps ​

Wat is releasemanagement in de DevOps-context en wat zijn de belangrijkste voordelen?

Als ik aan releasebeheer denk, zijn de verschillende vragen die bij me opkomen: welke release draait in welke omgeving en welke patches zijn daar toegepast? Welke zijn de hotfixes die zijn geïmplementeerd en voor welke klant is het?

Ik weet het, het is de hoofdpijn van de releasemanager om al deze informatie bij te houden. We weten eerder dat releasemanagement vroeger noch de verantwoordelijkheid was van de Dev of de Ops. Het was een apart releasemanagementteam dat de softwarerelease-activiteiten beheerde.

En een apart bord genaamd CCB en CAB, wijzigingscontrolebord, wijzigingsgoedkeuringsbord, werd gebruikt om de verantwoordelijkheid voor het beheren van de wijzigingen af ​​te handelen en te controleren wat wordt toegepast en wat niet.

Maar nu zijn de dingen veranderd met de DevOps. En het is niet meer alleen de verantwoordelijkheid van de releasemanager, maar het hele team.

Zoals we eerder DevOps hebben gedefinieerd, is DevOps een heel team dat eigenaar is van de software vanaf het begin totdat deze wordt geleverd aan de productie en ervoor zorgt dat de applicatie presteert in de productie volgens de vereisten.

In DevOps is de softwareontwikkelingstaak dus niet voltooid, tenzij de code op de site wordt geïmplementeerd en gedurende een bepaalde periode met succes wordt gecontroleerd op zijn prestaties.

Daarom ligt de verantwoordelijkheid van de softwarelevering en de live-uitvoering ervan bij iedereen in het team. Dat geldt ook voor de releasebeheertaken.

We zullen meer leren over releasebeheeraspecten in DevOps.

Laten we begrijpen wat releasebeheer is?

Zoals we allemaal weten, is releasebeheer vanuit een breed perspectief het beheren en onderhouden van de informatie, welke versie van de software of de componenten worden geïmplementeerd in welke omgevingen, wanneer en hoe deze is geïmplementeerd.

hoe assert te gebruiken in selenium webdriver

Dit gaat dus allemaal over releasemanagement.

Laten we eens kijken hoe het Release Management Process werkt.

In tegenstelling tot vroeger zijn er geen formele CCB's in DevOps. Maar het betekent niet dat er geen goedkeuringen zijn voor de wijzigingen.

Goedkeuringen gebeuren ook via een tool. De tools voor verandermanagement, zoals Jeera en ClearQuest, worden gebruikt om wijzigingen vast te leggen en goed te keuren en deze naar het Dev-team te leiden voor het opbouwen van een achterstand als technische schuld of een nieuwe vereiste.

Deze veranderingen die door het programmateam worden opgepikt, worden gebouwd, getest en automatisch geïmplementeerd in de productie, samen met de geautomatiseerde leveringspijplijn. Maar elke wijziging wordt vastgelegd in het versiebeheer en deze wijzigingen worden gecontroleerd en getest gedurende de hele leveringspijplijn.

Dus alle wijzigingen die door het team worden aangebracht, worden vastgelegd in de versiebeheertool en wat met succes is geïmplementeerd in de omgevingen en hun configuraties zijn beschikbaar in de configuratietool.

Dus zowel versiebeheer als configuratiebeheer geven ons samen een duidelijk beeld van wat er wordt vrijgegeven, wanneer het wordt vrijgegeven, waar het wordt vrijgegeven en hoe het wordt vrijgegeven.

In de context van DevOps is het dus in feite het versiebeheer en het configuratiebeheer dat fungeert als een tool voor releasebeheer. Deze twee processen en tools fungeren dus als een CCB, wat we noemen in onze traditionele ontwikkelmethode.

In feite automatiseert het het werk van een CCB-manager, die idealiter elk van deze wijzigingen of releases verifieert en certificeert om het in productie te laten gaan.

In het geval van DevOps is het niet de release die wordt gecertificeerd, maar de hele leveringspijplijn die op een geautomatiseerde manier wordt gecertificeerd, samen met handmatige poorten.

Als zodanig is releasebeheer geen afzonderlijke activiteit als onderdeel van DevOps, maar het is al ingebouwd als onderdeel van de DevOps-pijplijn of leveringspijplijn, samen met versiebeheer, configuratiebeheer en implementatiepijplijn.

Dus versiebeheer in combinatie met configuratiebeheer maakt het releasebeheer.

En terwijl we naar de DevOps-praktijk gaan, waar we streven naar leveringen over een periode van enkele uren, is het praktisch onmogelijk om dergelijke frequente implementaties en de registratie en het onderhoud ervan handmatig te beheren door de traditionele releasebeheerprocessen, waar ze handmatig worden beheerd met automatisering. in zeer kleine mate.

Totale automatisering van het releasemanagementproces is dus een must.

Ook hoeven we in de DevOps-pijplijn geen controle te hebben over de implementaties, als de wijzigingen zijn goedgekeurd, gebouwd, getest en in versiebeheer komen, worden ze automatisch toegepast op de productie. Natuurlijk zijn er functietoetsen om ze in of uit te schakelen tijdens de productie.

Controle en traceerbaarheid van elke wijziging zijn een van de grootste voordelen die we hebben vanuit het perspectief van releasemanagement. Dus wanneer we de DevOps-pijplijn of leveringspijplijn bouwen, bouwen we deze logboekregistratie en auditing in de pijplijn, zodat de real-time gebeurtenissen in de omgeving worden geregistreerd en gecontroleerd.

Dus we gaan de daadwerkelijke gebeurtenissen krijgen die naar voren komen als gevolg van de actie van het implementeren van de applicatie in de omgeving. Omdat het een kortere en kleinere release is, is het vrij eenvoudig om deze wijzigingen door de hele pijplijn te volgen.

We zijn bij het Tools-gedeelte van het Releasebeheer gekomen.

Release Management-tools die op de markt beschikbaar zijn, zorgen ervoor dat de automatische implementatie van wijzigingen tijdig en foutloos is en ze zijn erop gericht om de maximale waarde aan de gebruikers te leveren.

In feite zijn het de implementatietools die worden gebruikt in de leveringspijplijn tijdens de geautomatiseerde implementatie.

XL Release is zo'n tool voor releasebeheer die specifiek is voor Continuous Deployment. Zoals ik al eerder zei, helpen deze tools de DevOps-teams bij het ontwerpen van hun implementatiemodel en bij het bewaken van de releases door alle taken met betrekking tot de implementatie en het beheer van de releases te automatiseren.

Plutora is zo'n robuust hulpmiddel dat een on-demand softwaretoolset voor Enterprise IT Release Management biedt die helpt bij het leveren van de releases.

Het Release Lifecycle Management-product van BMC Software is ook een tool voor releasebeheer van BMC Software die end-to-end inzicht biedt in de voortgang van de softwarerelease. Het lijkt erop dat gebruikers via een centraal webportaal de applicatie-ontwikkeling, kwaliteitscontrole en productie kunnen volgen om de implicaties van elke aangebrachte wijziging te volgen.

Er is nog een tool van XebiaLabs. Deze tool maakt het mogelijk om de pijplijn voor hun softwareversies te plannen, automatiseren en analyseren.

Laten we de voordelen van het geautomatiseerde releasemanagementsysteem van DevOps op een rijtje zetten.

Allereerst helpen de volledige releasebeheerprocessen, die worden geautomatiseerd, het team om snellere en consistente leveringen aan de klanten te krijgen.

We hebben geleerd dat, telkens wanneer een release of wijziging door een continue leveringspijplijn in de DevOps-omgeving wordt gepusht, alle informatie over wat er werkelijk in de omgeving is gebeurd, duidelijk in de logboeken wordt opgeschreven.

We zullen dus feitelijke dingen of real-time gebeurtenissen hebben die in het logboek worden opgeschreven, zoals wat er is gebeurd tijdens de daadwerkelijke implementatie van de release in een bepaalde omgeving.

Hiermee hebben we dus een zeer sterke controle en traceerbaarheid van wijzigingen die in DevOps worden bijgehouden.

Elke keer dat iemand wijzigingen aanbrengt in een deel van de leveringspijplijn, zal worden getraceerd.

We hebben versiebeheer, wat er is gewijzigd, wat is geïmplementeerd en de respectievelijke configuraties. Dit geeft dus een duidelijk zicht op de details over, wat is afgeleverd, waar het is afgeleverd, wanneer en hoe, in het geval van elke release.

Automatisering van de release pipeline is een andere leuke feature van de DevOps, die handmatig ingrijpen zoveel mogelijk voorkomt en het is ook heel eenvoudig terug te traceren bij release mislukkingen, door de mislukte release te vergelijken met de succesvolle release.

Automatisering van de release-pijplijn biedt ons dus binnen enkele minuten een hogere kwaliteit van levering. Menselijke fouten, consistentie en duidelijk meer vertrouwen in de leveringen worden gemaakt.

Dit stelt het team ook in staat om te voelen dat de implementatie of ‘vrijgeven voor productie’ een routine of dagelijks schema is, door hen de releasepijplijn en de implementaties ervan grondig te laten begrijpen.

Het lijdt geen twijfel dat dit comfort en tijdwinst de mensen in staat stelt zich meer op de andere belangrijke dingen dan op de routinezaken te concentreren.

We weten eerder, releases vonden plaats na sluitingstijd of vroege uren en over het algemeen in het weekend. En het team moest deze releases op die tijdstippen ondersteunen.

Denk aan alle stressvolle momenten vóór de vrijlating die zouden plaatsvinden, wakker zijn in de late uurtjes of 's ochtends vroeg om de uitzending uit te voeren, uiteindelijk menselijke fouten maken, vergeten iets te veranderen en dan God bidden om de vrijlating succesvol te maken enzovoort.

Dus nu heeft de huidige DevOps-methode van implementatie en releasemanagement een gordijn gesloten voor al onze eerdere ellende van stressvolle momenten.

hoe je een .dat-bestand opent

Geen weekendimplementaties meer, geen slapeloze nachten en geen implementatiestress meer. Alles is geautomatiseerd. Het vrijgeven van nieuwe functies of het bijwerken van wijzigingen is dus geen stressvolle bezigheid meer.

De DevOps-implementatiemethode omvat geen downtime of enige vorm van onderbreking voor de gebruikers, in tegenstelling tot het eerdere geval van het verzenden van vervelende downtime-berichten naar alle klanten en hen te vragen te stoppen met het gebruik van de service of hen plotselinge verrassingen te geven met de onverwachte problemen die zich hebben voorgedaan tijdens de upgrade en het verder verlengen van de downtime.

Belachelijk !! Waarom zouden ze zich zorgen moeten maken over de software-upgrades die we uitvoeren of waarom zouden ze problemen hebben met deze updates?

Stoor de gebruikers niet met de updates die het softwareteam op de server aanbrengt. Daarom heeft de DevOps-manier om releases te maken een einde gemaakt aan al deze problemen.

Geen nachtelijke implementaties meer, geen patches meer die aan de klanten worden geleverd en geen serviceonderbreking meer.

Hiermee ronden we het onderwerp ‘Release Management in DevOps’ af.

In onze aanstaande tutorial , zullen we meer leren over de Application Performance Monitoring-proces in DevOps.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^