Meny

Slipp ledelse i DevOps

release management devops

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er Release Management i DevOps?

Håper du hadde vært tydelig på Configuration Management konsept i DevOps fra vår siste opplæring.

Som vi definerte DevOps tidligere, er DevOps hele teamet som eier programvaren fra starten til den leveres til produksjonen og sørger for at applikasjonen utfører i produksjonen i henhold til kravene.

Anbefalt lesing => De beste opplæringsveiledningene for DevOps noensinne

Slipp ledelse i DevOps

Derfor er 'Release Management' som vi alle vet å administrere hvilken versjon av programvaren som distribueres til hvilket miljø, når og hvordan er ikke bare ansvaret for Release Manager, men hele teamets ansvar i DevOps.

De viktigste fordelene med Release Management i DevOps kan oppsummeres som,

    • Raskere og jevnlige leveranser.
    • Sterk revisjon og sporbarhet av endringer.
    • Automatisering av utgivelsesprosessen: Høyere kvalitet, konsistens, selvtillit.
    • Øker tilliten gjennom vellykkede og konsekvente leveranser.
    • Å frigjøre - ubelastet aktivitet
    • Ingen nedetid

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

Transkripsjon:

I denne blokken vil vi forstå Utgivelsesadministrasjonsprosedyre for DevOps .

Hva er Release Management i DevOps-sammenheng, og hva er de viktigste fordelene?

Når jeg tenker på frigjøringsadministrasjon, er de forskjellige spørsmålene som dukker opp i tankene mine, hvilken utgivelse kjører i hvilket miljø, og hvilke oppdateringer har blitt brukt der? Hvilke hurtigreparasjoner er distribuert og for hvilken kunde det er?

Jeg vet, det er hodepinen til utgivelsesansvarlig å holde oversikt over all denne informasjonen. Vi vet at utgivelsesadministrasjon tidligere ikke var ansvaret for Dev eller Ops. Det var et eget team for frigjøringsledelse som pleide å administrere programvareutgivelsesaktivitetene.

Og et eget styre kalt CCB og CAB, endre kontrollkort, endre godkjenningstavle, brukes til å håndtere ansvaret for å administrere endringene og kontrollere hva som brukes og hva som ikke er.

Men nå har ting endret seg med DevOps. Og det er ikke mer bare frigjøringsansvarliges ansvar, men hele teamet.

Som vi definerte DevOps tidligere, er DevOps et helt team som eier programvaren fra starten til den leveres til produksjonen og sørger for at applikasjonen utfører i produksjonen i henhold til kravene.

I DevOps er programvareutviklingsoppgaven ikke fullført, med mindre koden distribueres på nettstedet og overvåkes for ytelse med hell i over en bestemt periode.

Derfor ligger ansvaret for programvareleveransen og ytelsen i live for alle i teamet. Det gjør også frigjøringsadministrasjonsoppgavene.

Vi vil lære mer om Release management-aspekter i DevOps.

La oss forstå Hva er Release Management?

Som vi alle vet, fra et bredt perspektiv, styrer og vedlikeholder frigjøringsadministrasjonen informasjonen, hvilken versjon av programvaren eller komponentene som er distribuert til hvilke miljøer, når og hvordan den ble distribuert.

youtube video downloader programvare for pc

Så alt handler om frigjøringsadministrasjon.

La oss se hvordan Release Management Process fungerer.

I motsetning til tidligere er det ingen formelle CCB-er i DevOps. Men det betyr ikke at det ikke er godkjent endringene.

Godkjenninger skjer også via et verktøy. Verktøyene for endringsadministrasjon som Jeera og ClearQuest brukes til å utføre registrering og godkjenning av endringer og dirigere dem til Dev-teamet for å bygge formål til en restanse som teknisk gjeld eller et nytt krav.

Disse endringene plukket opp av programteamet er bygget, testet og blir automatisk distribuert til produksjonen sammen med den automatiske leveringsrørledningen. Men hver endring blir logget, i versjonskontrollen og disse endringene blir revidert og testet gjennom hele leveringsrørledningen.

Så uansett hvilke endringer teamet gjør, blir det registrert i versjonskontrollverktøyet, og det som vellykket ble distribuert til miljøene og deres konfigurasjoner, er tilgjengelig i konfigurasjonsverktøyet.

Derfor gir både versjonskontroll og konfigurasjonsadministrasjon oss et klart bilde av hva som slippes, når den slippes, hvor den slippes og hvordan den slippes.

Så i sammenheng med DevOps er det i utgangspunktet versjonskontrollen og konfigurasjonsadministrasjonen som fungerer som et frigjøringsstyringsverktøy. Så disse to prosessene og verktøyene fungerer som en CCB, som vi kaller i vår tradisjonelle utviklingsmetode.

I utgangspunktet automatiserer det arbeidet til en CCB-leder, som ideelt sett verifiserer hver av disse endringene eller utgivelsene og sertifiserer for å la det gå til produksjon.

I tilfelle DevOps er det ikke utgivelsen som blir sertifisert, men hele leveringsrørledningen som blir sertifisert på en automatisk måte sammen med manuelle porter.

Som sådan er ikke frigjøringsadministrasjon en egen aktivitet som en del av DevOps, men den er allerede innebygd som en del av DevOps-rørledningen eller leveringsrørledningen sammen med versjonskontroll, konfigurasjonsadministrasjon og distribusjonsrørledning.

Så, versjonskontroll når den er koblet sammen med konfigurasjonsadministrasjon, gjør frigjøringsadministrasjonen.

Og mens vi går inn i DevOps-praksis hvor vi satser på å levere i løpet av noen få timer, er det praktisk talt umulig å administrere så hyppige distribusjoner og registrering og vedlikehold manuelt av de tradisjonelle utgivelsesadministrasjonsprosessene der de administrerer manuelt med automatisering i veldig liten grad.

Så total automatisering av prosessen for frigjøringsadministrasjon er et must.

I DevOps-rørledningen trenger vi ikke å kontrollere distribusjonene, hvis endringene blir godkjent, bygget, testet og kommer inn i versjonskontrollen, blir de automatisk brukt på produksjonen. Selvfølgelig er funksjonskoblinger der for å slå på eller av for å kontrollere dem i produksjonen.

Revisjon og sporbarhet av enhver endring er en av de sterkeste fordelene vi har fra frigjøringsstyringsperspektivet. Så når vi bygger DevOps-rørledningen eller leveringsrørledningen, bygger vi denne loggføringen og revisjonen i rørledningen, slik at sanntidshendelser på miljøet blir registrert og revidert.

Så vi skal få de faktiske hendelsene som kommer ut på grunn av handlingen med å distribuere applikasjonen til miljøet. Å være kortere og mindre utgivelse, er det ganske enkelt å spore disse endringene gjennom hele rørledningen.

Vi har kommet til Verktøy-delen av frigjøringsledelsen.

Release Management-verktøy som er tilgjengelige på markedet sørger for at automatisk distribusjon av endringer er rettidig og feilfri, og de tar sikte på å levere maksimal verdi til brukerne.

I utgangspunktet er de distribusjonsverktøyene som brukes i leveringsrørledningen under den automatiserte distribusjonen.

XL Release er et slikt verktøy for frigjøringsadministrasjon som er spesifikt for kontinuerlig distribusjon. Som jeg sa tidligere, hjelper disse verktøyene DevOps-teamene med å designe distribusjonsmodellen og hjelpe til med å overvåke utgivelsene ved å automatisere alle oppgavene knyttet til distribusjonen og administrere utgivelsene.

Plutora er et annet så robust verktøy som gir et on-demand Enterprise IT Release Management-programvaresett som hjelper til med å levere utgivelsene.

BMC Software's Release Lifecycle Management-produkt er også et frigjøringsstyringsverktøy fra BMC Software som gir end-to-end synlighet av programvareutgivelsens fremgang. Via en sentral nettbasert portal ser det ut til at brukerne kan spore applikasjonsutvikling, kvalitetssikring og produksjon for å overvåke implikasjonene av enhver endring.

Det er et annet verktøy fra XebiaLabs. Dette verktøyet gjør det mulig å planlegge, automatisere og analysere rørledningen for programvareutgivelser.

La oss liste fordelene med det automatiserte frigjøringsstyringssystemet til DevOps.

Først og fremst hjelper hele frigjøringsadministrasjonsprosessene, som blir automatisert, teamet til å få raskere og konsistente leveranser til kundene.

Vi lærte at når enhver utgivelse eller endring blir presset gjennom en kontinuerlig leveringsrørledning i DevOps-miljøet, ville all informasjon om hva som faktisk har skjedd i miljøet, bli klart skrevet ned i loggene.

Så vi vil ha faktiske ting eller hendelser i sanntid som er skrevet ned i loggen, fra det som skjedde under den faktiske distribusjonen av utgivelsen til et bestemt miljø.

Så med dette har vi en veldig sterk revisjon og sporbarhet av endringer som opprettholdes i DevOps.

Når som helst, vil noen gjøre endringer i noen del av leveringsrørledningen, vil bli sporet.

Vi vil ha i versjonskontroll, hva som er endret, hva som er distribuert og dets respektive konfigurasjoner. Så dette gir en klar oversikt over detaljene om, hva som er levert, til hvor det har blitt levert, når og hvordan, i tilfelle hver utgivelse.

Automatisering av utgivelsesrørledningen er en annen flott funksjon i DevOps, som forhindrer manuell inngripen så mye som mulig, og det er også veldig enkelt å spore tilbake i tilfelle utgivelsesfeil, ved å sammenligne den mislykkede utgivelsen med den vellykkede utgivelsen.

Så automatisering av utgivelsesrørledningen gir oss høyere leveringskvalitet innen få minutter. Menneskelige feil, konsistens og åpenbart større tillit til leveransene gjøres.

Dette gjør det også mulig for teamet å føle at distribusjonen eller 'frigjøring til produksjon' som en rutinemessig eller daglig tidsplan, ved å få dem til å forstå frigjøringsrørledningen og dens distribusjoner grundig.

Ingen tvil om at denne komforten og tidsbesparelsen gjør at folk kan fokusere mer på de andre viktige tingene enn de rutinemessige tingene.

Vi vet tidligere at utgivelser pleide å skje etter timer eller tidlig og generelt i helgene. Og teamet ble pålagt å støtte disse utgivelsene på disse tidspunktene.

Tenk på alle de stressende øyeblikkene før løslatelsen som ville skje, å være våken om ettermiddagen eller tidlig om morgenen for å utføre distribusjonen, ender med å begå menneskelige feil, glemme å gjøre en forandring, og så be Gud om at løslatelsen skulle lykkes og så videre.

Så nå har den nåværende DevOps-metoden for distribusjon og frigjøringsadministrasjon lagt et gardin til alle våre tidligere problemer med stressende øyeblikk.

teknisk support intervju spørsmål og svar

Ikke flere helgdistribusjoner, ikke flere søvnløse netter og ikke mer distribusjonsstress. Alt er automatisert. Så å slippe nye funksjoner eller oppdatere endringer er ikke mer en stressende aktivitet.

DevOps-metoden for distribusjon innebærer ingen nedetid eller noen form for avbrudd for brukerne mot det tidligere tilfellet med å sende irriterende nedetidsmeldinger til alle kundene og be dem om å slutte å bruke tjenesten eller gi dem plutselige overraskelser med de uventede problemene som oppstod under oppgraderingen og videre utvide nedetid.

Latterlig !! Hvorfor skulle de bry seg om programvareoppgraderingene vi gjør, eller hvorfor skulle de være i trøbbel med disse oppdateringene?

Ikke forstyrr brukerne med oppdateringer programvareteamet gjør på serveren. Derfor har DevOps måte å lage utgivelser gjort slutt på alle disse problemene.

Ikke flere distribusjoner over natten, ikke flere oppdateringer som leveres til kundene, og ikke mer serviceavbrudd.

Med dette fullfører vi temaet ‘Release Management in DevOps’.

I vår kommende opplæring , vil vi lære mer om Overvåkingsprosess for applikasjonsytelse i DevOps.

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^