Menu

Release Management i DevOps

release management devops

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er Release Management i DevOps?

Håber du ville have været klar over det Konfigurationsstyringskoncept i DevOps fra vores sidste tutorial.

Som vi definerede DevOps tidligere, er DevOps hele teamet, der ejer softwaren fra starten, indtil den leveres til produktionen og sikrer, at applikationen udfører i produktionen i henhold til kravene.

Anbefalet læsning => Bedste nogensinde DevOps-træningsvejledninger

Release Management i DevOps

Derfor er 'Release Management', som vi alle ved, at styre, hvilken version af softwaren der er implementeret i hvilket miljø, hvornår og hvordan er ikke kun Release Manager's ansvar, men hele teamets ansvar i DevOps.

De største fordele ved Release Management i DevOps kan opsummeres som,

    • Hurtigere og ensartede leverancer.
    • Stærk revision og sporbarhed af ændringer.
    • Automatisering af frigivelsesprocessen: Højere kvalitet, konsistens, tillid.
    • Øger tilliden gennem vellykkede og ensartede leverancer.
    • At frigive - ubelastet aktivitet
    • Ingen nedetid

VIDEO Part4 Block 2: Release Management- 17 minutter og 12 sekunder

Udskrift:

I denne blok vil vi forstå Release Management-procedure for DevOps .

Hvad er Release Management i DevOps-sammenhængen, og hvad er dens primære fordele?

Når jeg tænker på frigørelsesstyring, er de forskellige spørgsmål, der opstår i mit sind, hvilken frigivelse kører i hvilket miljø, og hvilke patches er der anvendt der? Hvilke hotfixes er der blevet implementeret, og for hvilken kunde er det?

Jeg ved, det er frigivelsesmanagers hovedpine at holde styr på alle disse oplysninger. Vi ved, at frigivelsesstyring tidligere ikke tidligere var Dev's eller Ops 'ansvar. Det var et separat frigørelsesstyringsteam, der plejede at styre softwareudgivelsesaktiviteterne.

Og et separat bord kaldet CCB og CAB, skift kontrolkort, skift godkendelseskort, der bruges til at håndtere ansvaret for at styre ændringerne og kontrollere, hvad der anvendes, og hvad der ikke er.

Men nu er tingene ændret med DevOps. Og det er ikke mere bare frigivelsesmanagers ansvar, men hele teamet.

Som vi definerede DevOps tidligere, er DevOps et helt team, der ejer softwaren fra starten, indtil den leveres til produktionen og sikrer, at applikationen udfører i produktionen i henhold til kravene.

Således i DevOps, medmindre koden er implementeret på webstedet og overvåges for dens præstation med succes i over en bestemt periode, er softwareudviklingsopgaven ikke afsluttet.

Derfor ligger ansvaret for softwareleveringen og dens ydeevne i live hos alle i teamet. Det gør frigørelsesstyringsopgaverne også.

Vi lærer mere om frigørelsesstyringsaspekter i DevOps.

Lad os forstå Hvad er Release Management?

Som vi alle ved, fra et bredt perspektiv styrer og vedligeholder frigivelsesadministration informationerne, hvilken version af softwaren eller komponenterne er implementeret i hvilke miljøer, hvornår og hvordan den blev implementeret.

top 50 sql vanskelige interviewspørgsmål pdf

Så alt handler om frigivelsesstyring.

Lad os se, hvordan Release Management Process fungerer.

I modsætning til tidligere er der ingen formelle CCB'er i DevOps. Men det betyder ikke, at der ikke er foretaget godkendelser af ændringerne.

Godkendelser sker også via et værktøj. Ændringsstyringsværktøjerne som Jeera og ClearQuest bruges til at udføre registrering og godkendelse af ændringer og dirigere dem til Dev-teamet til bygningsformål til en efterslæpning som teknisk gæld eller et nyt krav.

Disse ændringer, der hentes af programteamet, bygges, testes og distribueres automatisk til produktionen sammen med den automatiske leveringsrørledning. Men hver ændring bliver logget, i versionskontrollen, og disse ændringer revideres og testes i hele leveringsrørledningen.

Så uanset hvilke ændringer der foretages af teamet, registreres det i versionskontrolværktøjet, og hvad der med succes blev implementeret i miljøerne og deres konfigurationer er tilgængelige i konfigurationsværktøjet.

Derfor giver både versionskontrol og konfigurationsstyring os et klart billede af, hvad der frigives, hvornår det frigives, hvor det frigives, og hvordan det frigives.

Så i forbindelse med DevOps er det grundlæggende versionskontrol og konfigurationsstyring, der fungerer som et frigørelsesstyringsværktøj. Så disse to processer og værktøjer fungerer som en CCB, som vi kalder i vores traditionelle udviklingsmetode.

Dybest set automatiserer det arbejdet hos en CCB-manager, som ideelt verificerer hver af disse ændringer eller frigivelser og certificerer for at lade det gå til produktion.

I tilfælde af DevOps er det ikke frigivelsen, der bliver certificeret, men hele leveringsrørledningen, der bliver certificeret på en automatisk måde sammen med manuelle porte.

Som sådan er frigivelsesadministration ikke en separat aktivitet som en del af DevOps, men den er allerede indbygget som en del af DevOps-rørledningen eller leveringsrørledningen sammen med versionskontrol, konfigurationsstyring og implementeringsrørledning.

Så versionskontrol, når det kombineres med konfigurationsstyring, gør frigørelsesadministrationen.

Og mens vi bevæger os ind i DevOps-praksis, hvor vi målretter mod at levere inden for en periode på få timer, er det praktisk taget umuligt at styre så hyppige implementeringer og dets registrering og vedligeholdelse manuelt ved hjælp af de traditionelle frigørelsesstyringsprocesser, hvor de administrerer manuelt med automatisering i meget lille grad.

Så total automatisering af frigørelsesstyringsprocessen er et must.

Også i DevOps-pipeline behøver vi ikke kontrollere implementeringerne, hvis ændringerne er godkendt, bygget, testet og kommer ind i versionskontrollen, bliver de automatisk anvendt på produktionen. Selvfølgelig er funktionskontakter der for at tænde eller slukke for at kontrollere dem i produktionen.

Revision og sporbarhed af enhver ændring er en af ​​de stærkeste fordele, vi har fra frigørelsesstyringsperspektivet. Så når vi bygger DevOps-rørledningen eller leveringsrørledningen, bygger vi denne logning og revision inden for rørledningen, så realtidshændelser på miljøet registreres og revideres.

Så vi vil få de faktiske hændelser, der kommer ud på grund af handlingen med at implementere applikationen i miljøet. At være kortere og mindre frigivelse er det ret nemt at spore disse ændringer gennem hele rørledningen.

Vi er kommet til værktøjsdelen i frigørelsesledelsen.

Release Management-værktøjer, der er tilgængelige på markedet, sikrer, at den automatiske implementering af ændringer er rettidig og fejlfri, og de sigter mod at levere den maksimale værdi til brugerne.

Dybest set er de implementeringsværktøjerne, der bruges i leveringsrørledningen under den automatiserede implementering.

XL Release er et sådant frigivelsesstyringsværktøj, der er specifikt for kontinuerlig implementering. Som jeg sagde tidligere, hjælper disse værktøjer DevOps-holdene med at designe deres implementeringsmodel og hjælpe med at overvåge udgivelserne ved at automatisere alle de opgaver, der er relateret til implementeringen og styre udgivelserne.

Plutora er et andet så robust værktøj, der leverer et on-demand Enterprise IT Release Management-softwareværktøjssæt, der hjælper med at levere udgivelserne.

BMC Softwares Release Lifecycle Management-produkt er også et frigørelsesstyringsværktøj fra BMC Software, der giver end-til-end-synlighed af softwareudgivelsens fremskridt. Via en central webbaseret portal ser det ud til, at brugerne kan spore applikationsudvikling, kvalitetssikring og produktion for at overvåge implikationerne af enhver foretaget ændring.

Der er et andet værktøj fra XebiaLabs. Dette værktøj gør det muligt at planlægge, automatisere og analysere rørledningen til deres softwareudgivelser.

Lad os liste fordelene ved det automatiserede frigørelsesstyringssystem i DevOps.

Først og fremmest hjælper hele frigørelsesstyringsprocesserne, der automatiseres, teamet med at få hurtigere og ensartede leveringer til kunderne.

Vi lærte, at når enhver frigivelse eller ændring skubbes gennem en kontinuerlig leveringsrørledning i DevOps-miljøet, ville alle oplysninger om, hvad der faktisk er sket i miljøet, blive skrevet tydeligt ned i logfilerne.

Så vi vil have egentlige ting eller realtidshændelser, der er nedskrevet i loggen, hvad der skete under den faktiske implementering af frigivelsen til et bestemt miljø.

Så med dette har vi en meget meget stærk revision og sporbarhed af ændringer, der opretholdes i DevOps.

Når som helst, vil nogen foretage ændringer i en hvilken som helst del af leveringsrørledningen, spores.

Vi har versionskontrol, hvad der er blevet ændret, hvad der er blevet implementeret og dets respektive konfigurationer. Så dette giver en klar synlighed på detaljerne om, hvad der er leveret, til hvor det er blevet leveret, hvornår og hvordan, i tilfælde af hver frigivelse.

Automatisering af frigørelsesrørledningen er en anden stor funktion i DevOps, der forhindrer manuel indgriben så meget som muligt, og det er også meget let at spore tilbage i tilfælde af frigivelsesfejl ved at sammenligne den mislykkede frigivelse med den vellykkede frigivelse.

Så automatisering af frigørelsesrørledningen giver os den højere leveringskvalitet inden for få minutter. Der foretages menneskelige fejl, konsistens og tydeligvis større tillid til leverancerne.

Dette gør det også muligt for teamet at føle, at implementeringen eller 'frigivelse til produktion' som en rutinemæssig eller daglig tidsplan ved at få dem til at forstå frigivelsesrørledningen og dens implementeringer grundigt.

Ingen tvivl om, at denne komfort og tidsbesparelse giver folk mulighed for at fokusere mere på de andre vigtige ting end de rutinemæssige ting.

Vi ved det tidligere, at udgivelser plejede at ske efter timer eller tidlige timer og generelt i weekenden. Og holdet var forpligtet til at støtte disse udgivelser på disse tidspunkter.

Tænk på alle de stressende øjeblikke før løsladelsen, der ville ske, at være vågen om eftermiddagen eller tidligt om morgenen for at udføre indsættelsen, ender med at begå menneskelige fejl, glemme at foretage en ændring og derefter bede Gud om at gøre frigivelsen vellykket og så videre.

Så nu har den nuværende DevOps-metode til implementering og frigivelsesadministration lagt et forhæng til alle vores tidligere problemer med stressende øjeblikke.

bedste verden af ​​warcraft private servere

Ikke flere weekendudplaceringer, ikke flere søvnløse nætter og ikke mere implementeringsstress. Alt er automatiseret. Så frigivelse af nye funktioner eller opdatering af ændringer er ikke mere en stressende aktivitet.

DevOps-metoden til implementering involverer ingen nedetid eller nogen form for afbrydelser for brugerne i forhold til det tidligere tilfælde om at sende irriterende nedetidsmeddelelser til alle kunder og bede dem om at stoppe med at bruge tjenesten eller give dem pludselige overraskelser med de uventede problemer, der opstod under opgraderingen og yderligere udvidelse af nedetid.

Latterligt !! Hvorfor skulle de være generet af de softwareopgraderinger, vi laver, eller hvorfor skulle de være i problemer med disse opdateringer?

Forstyr ikke brugerne med de opdateringer, som softwareteamet foretager på serveren. Derfor har DevOps måde at lave frigivelser på, at alle disse problemer er stoppet.

Ikke flere implementeringer natten over, ikke flere patches, der leverer til kunderne, og ikke mere serviceafbrydelse.

Med dette fuldender vi emnet 'Release Management in DevOps'.

I vores kommende vejledning , vil vi lære mere om Overvågningsproces for applikationsydelse i DevOps.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^