Sidst opdateret den: 07 October 2020
De bedste praksisser til ITIL-frigivelseadministration, der er forklaret her, er baseret på en mellemstor telekommunikationsvirksomhed. Virksomheden stod over for flere problemer, der kostede dem ca. 25 % af deres kunder og et fald i deres produktivitet. Hovedårsagen var manglen på en effektiv frigivelseadministrationsproces og effektive procedurer. Find ud af, hvordan dette selskab afbødede frigivelsesfejl, og øgede deres frigivelser i løbet af tre måneder.
"Frigivelseadministration er processen med at styre, planlægge og kontrollere en softwarebygning gennem forskellige stadier og miljøer" - Wikipedia
"Frigivelseadministration handler om bygning, test og implementering, mens løbende levering handler om bygning, test og implementering ved hjælp af automatisering." - Charles Betz, forskningsanalytiker Forrester
"For mig er test af software det vigtigste del af automatiseringen." -Jayne Groll CEO DevOps Institute
Oversigt
Et mellemstort teleselskab mistede omkring 25 procent af sine kunder over en periode på tre måneder på grund af flere forsinkede frigivelser af kritisk software. Det var tydeligt, at den eksisterende frigivelseadministrationsproces ikke var effektiv, og virksomheden var nødt til at foretage fejlfinding og nå frem til en konkret proces for at rette op på tingene.
Virksomheden dannede et nyt frigivelseadministrationsteam for at vurdere og strømline sit nuværende frigivelseadministrationsprocesflow. I de følgende tre måneder var det nye team i stand til at udsætte både de afventende frigivelser og to planlagte frigivelser af genudviklede applikationer. Nedenfor ser du, hvordan teamet strømlinede ITIL-frigivelseadministrationsprocessen. De trin, teamet tog, afspejler bedste praksis, der kan anvendes af enhver IT-organisation, inklusive din.
Det nye team ønskede et detaljeret billede af det aktuelle frigivelseadministrationsprocesflow. De begyndte med en række walkthrough-sessioner med nøglepersoner involveret i softwareprocessen. I disse sessioner fik teamet at vide, at noget CRM-software havde været under release i to måneder efter færdiggørelse.
Baseret på kundens krav inkluderede CRM-softwaren et kravforlig. Den inkluderede også servicekreditter og sanktioner for telekunder, der oplevede problemer med nedetid, serviceforringelse og overførsel til en ny faktureringsplan. Forsinkelsen med at implementere CRM-softwaren betød, at flere af kunderne ikke kunne få deres servicekreditter eller refusioner til tiden, og at der ikke var noget sporingssystem til opdaterede statusanmodninger. Cirka 25 procent af erhverskunderne mistede tålmodigheden med systemet og forlod virksomheden.
I den eksisterende proces var berøringspunkterne, valideringen og verificeringsprocessen ikke problemfri på grund af hardwareindkøb, testmiljø og fraværet af en aftalt frigivelsescyklus.
For at håndtere denne situation fulgte det nye frigivelseadministrationsteam et par retningskorrigerende tips som anført nedenfor:
Da teamet fik et billede af den aktuelle tilstand i frigivelseadministrationsprocessen, besluttede de at fokusere på at definere og etablere en aftalt frigivelsescyklus. For at forstå frekvensen af frigivelse i produktion, måtte teamet forstå hyppigheden af den ikke-funktionelle test. Efter en diskussion med ingeniørholdene konkluderede teamet, at projektet krævede regression, ydeevne og integrationstest.
Frigivelsescyklussen blev udviklet til at opnå følgende:
Frigivelseadministrationsteamet startede med at eksperimentere med en ugentlig cyklus, men planen viste sig ikke at være mulig. Klientens databasemiljø kunne ikke opdateres hurtigt. Holdet prøvede derefter med cyklusser på to uger. Der var ingen øjeblikkelig indsigelse fra deltagerne, men en to-ugers cyklus mislykkedes de første to gange. Da de først havde overvundet nogle få miljømæssige flaskehalse og automatiseret nogle af testene, besluttede teamet, at en to-ugers cyklus var opnåelig.
Endelig etablerede teamet en cyklus, hvor der hver anden uge blev sat produktionsklar kode fra ingeniørholdet i systemtest. To uger senere frigav de koden til produktion.
Frigivelsescyklussen handlede ikke om, hvornår kunden ønskede frigivelsen. Den handlede om, hvornår teamet kunne levere den til markedet med det ønskede kvalitetsniveau. Men når teamet engagerede kunderne og gjorde dem til beslutningstagere, begyndte kunderne at støtte det.
Lette processer er nogle, der ikke kræver lange bureaukratiske godkendelser eller uendelige møder, for at der kan opnås enighed. De kræver normalt kun et minimal acceptabel mængde input og output. Hvad de mangler i mængde og bureaukrati, kompenserer de for ved at reagere på forandringer og folkelig vedtagelse.
Underbygningen af denne tilgang var imidlertid et problemfyldt spørgsmål om dokumentation. Teamet havde brug for at registrere, hvad der blev gjort, og hvordan det blev gjort. Ellers ville det være umuligt at gennemgå eller forbedre situationen.
Virksomheden besluttede at arbejde hen imod en dokumentationsstandard, der ville lade folk (teknikere og andre) læse og handle på dokumenter i stedet for at lade dokumenterne ligge på hylden.
Ingeniørteamet valgte Confluence, et kommercielt værktøj, til i fællesskab at dokumentere deres arbejde. De brugte softwaren til at skabe minimal, men effektiv dokumentation af, hvad de blev enige om at opbygge i hver arbejdscyklus. De registrerede, hvad de byggede, hvordan de byggede det, og hvad der var nødvendigt for at få det til at fungere. Det nye team så værdien i denne tilgang og rullede den ud (både tilgangen og værktøjet) til alle andre involverede i processen.
En række opgaver blev derefter oprettet for at frigive softwaren fra ingeniørholdene. Listen med opgaver omfattede:
En frigørelsesinfrastruktur sikrer, at alt er på plads til at implementere software og muliggøre brug. Frigivelsesadministrationsteamet tog tid at udvikle et konfigurationsadministrationssystem (CMS) og startede med at opbygge træstrukturen og konfigurationselementet (CI)-hierarki.
Holdet afholdt workshops med infrastruktur, applikationsudvikling og administrationsteam for at beslutte konfigurations-, ændrings- og frigivelsesprocesser. Det aftalte konceptuelle flow fra et værktøjsperspektiv er afbildet nedenfor..
Frigivelsesinfrastrukturen dækkede hardware, lagring, netværksforbindelser, båndbredde, softwarelicenser, brugerprofiler og adgangstilladelser. Menneskelige tjenester og færdigheder var også en del af frigivelsesinfrastrukturen. Hvis et stykke specialsoftware for eksempel skulle installeres og konfigureres, kunne de ikke udelukke tilgængeligheden eller omkostningerne ved at få sådanne færdigheder ind i infrastrukturplanen.
Det er afgørende at opdage eventuelle skjulte flaskehalse ved indkøb af den krævede hardware eller manglende færdigheder (f.eks. konfiguration af sikre netværk). Teamet måtte løse disse problemer før levering.
Denne standard var imidlertid ikke let at opretholde. Teamet stræbte efter at få frigivelsesinfrastrukturen på plads, så snart de startede på projektet. Selv efter seks ugers ledetid ventede de dog stadig på specialhukommelse og harddiske til testserverne.
Teamet identificerede bygge- og testopgaver, der kunne automatiseres, og kom med kriterierne og definitionerne for normale, standard- og nødændringer. Automatisering gjorde dem i stand til at udføre gentagne opgaver, uden at det krævede værdifulde menneskelige ressourcer. De kvalificerede også en række standardændringer baseret på risiko, gentagelighed og tid involveret i udførelsen.
Ændringer blev samlet for at justere med frigivelsescyklussen på to uger. Ændringsteams arbejdede med frigivelses- og implementeringsteams synkroniseret med frigivelseskalenderen, typer af frigivelse og tidlig livscyklussupport.
Forud for deres involvering i projektet lavede ingeniørholdene manuelt implementerbare pakker. På grund af dette var hver nye pakke ikke garanteret at være den samme som den foregående. Det var faktisk ikke engang garanteret, at det var den software, de havde bygget, med langt mindre garanti for at det at virker. Det tog ofte medarbejderne dage at oprette en pakke med funktionerne i en struktur, der kunne implementeres.
Frigivelsesadministrationsteamet udarbejdede straks en struktur og serviceaccept-kriterier for den pakke, som ingeniørteamet leverede og som skulle implementeres, og hjalp dem med at standardisere pakken. Dette udløste implementering af automatiserede processer til at bygge softwaren i den ensartede struktur for hvert frigivelsespunkt.
Da teamet havde automatiseret bekræftelsesprocessen for acceptkriterierne, blev udførelsen garanteret. For eksempel skal kode være unittestet inden levering og test implementeret for at sikre, at den kunne være. Som et resultat var frigivelsesadministrationsteamet i stand til at pakke, definere version på, teste og implementere den færdige kode med en enkelt kommando på meget kort tid.
Den nyetablerede frigivelsescyklus betød, at en frigivelse måtte testes for regression, ydeevne og integration på kun to uger for at teamet kunne frigive det i produktion. Teamet var i stand til at overvinde forskellige typer tests (integration og ydeevne) ved at have separate miljøer for hver type. Udfordringen med at imødekomme to måneders regressionstest i et to-ugers vindue syntes imidlertid umulig. Sådan gjorde de det.
Mens kombinationen af konfigurationsadministration, ændringskontrolproces og frigivelses- og implementeringsadministrationsprocesser blev integreret problemfrit, krævede hele processen toppunktet det ypperste af mennesker for at være muligt.
Frigivelsesadministrationsteamet understøttede vigtigheden ved at konstatere, at den udpegede frigivelsesadministrator ville forvente, at softwaren var klar på det tidspunkt, teamsene blev enige om. Teamet lavede en aftale om, at programlederen (i dette tilfælde slutbrugerkunden) ville forklare holdene, hvorfor denne frigivelse var vigtig.
Teamet anmodede om, at ingeniørteamsene skulle sikre, at softwaren, de leverede, var i overensstemmelse med en standard (versioneret, testet, dokumenteret og pakket). Teamet konstaterede også, at de ville anmode om denne standardpakke ved hver frigivelsescyklus. Dette gjorde den automatiserede proces lettere og mere ensartet og muliggjorde integration af feedback.
De følgende frigivelsesadministrationsmetrikker blev målt løbende for at tune frigivelsesadministrationsprocessen.
I løbet af hele transformationen var det største aktiv menneskerne. Frigivelsesadministrationsteamet tog deres perspektiver, problemer og udfordringer på en retfærdig og gennemsigtig måde og informerede ledelsen om det samme. De angav endda et par af de tidligste modtagere som forandringsagenter. De investerede meget i uddannelse, opmærksomhed og kommunikation og indførte derved en belønningsmekanisme for at anerkende positiv adfærd og vidensdeling.
Følgende workshops blev afholdt for konfigurations-, ændrings- og frigivelsesadministrationsteams uden undtagelse. Linemanagers var også tilgængelige for at validere workshoppenes effektivitet.
Resultatet af denne fem-dages workshop var øget klarhed for de involverede teams på forskellige berøringspunkter, leverancer og den samlede forretningseffekt. Der blev uddelt et cheat sheet til at opsummere de vigtigste læringspunkter i træningen.
Læring
Bundlinjen
Baseret på frigivelsesadministrationsteamets erfaring med at arbejde sammen med andre på projektet, indså de, at god frigivelsesadministration kræver hårdt arbejde, beslutsomhed og fantastisk kommunikation. Den største kompetence er imidlertid evnen til at gennemgå, lære og tilpasse forbedringer med effektivt samarbejde mellem mennesker i forbindelse med den magiske trekant for ændrings-, frigivelses- og implementeringsadministrationsprocesser.