Release Management

Sikrer planlagt og kontrolleret udrulning af software, hardware og grupperede Changes med minimal forstyrrelse af forretningen.

Af Kristoffer Bohmann

Formål

• Sikre at tekniske og ikke-tekniske faktorer ved en release håndteres under eet.
• Kommunikere til brugerne og styre deres forventninger.
• (Release-processen bruges ved omfattende eller kritiske udrulninger af hardware, software og bundlede Changes.)

Definitioner

De mest centrale begreber indenfor Release Management:

• Release-politik: Skriftlige dokumentation af hvem der gør hvad under en release, eventuelt et dokument for hvert system eller IT-service.
• Releaseplan: Projektplan for lancering af en release-pakke inklusive beskrivelser af test, rollback-planer (hvordan ruller vi tilbage hvis systemet fejler?) og implementering (hvad skal konkret gøres for at release softwaren / hardwaren?) - sikrer kvalitet og minimerer fejl
• Pakke/Package: Softwareopdateringer samlet i en pakke så det kan udrulles, testes og evt. tilbagerulles samlet. Releasen og dens servicevindue godkendes af Change Management inden lancering.
• Servicevindue: Tidsrum hvor en release har godkendelse til at blive lanceret.
• Definitive software library (DSL): Masterkopi af alt indkøbt og egenudviklet software som styres under Release-processen inklusive opdaterede data om softwarelicenser og konfigurationer af servere, databaser og systemer. Masterkopier kan med fordel opbevares i et versionsstyrings-system som for eksempel Subversion, mens konfigurationer registreres i virksomhedens CMDB.
• Definitive hardware store (DHS):
• CMDB: Configuration Management Database med dokumentation af fx en server og de databaser og systemer som ligger på serveren.

Processer

Vigtige processer og aktiviteter indenfor Release Management:

• Releaseplan for aktiviteter, ansvarlige og deadlines.
• Konfigurere og bygge releasen med de nødvendige komponenter; kan ofte automatiseres.
• Testplan: Inputs til Test Management med test cases og hvad der testes før/efter hver Release. Teste rollback-planer. Koordinere med Test Management.
• Lave indkøbsordrer på software, licenser og hardware.
• Godkendelser af udrulningen skaffes fra Change management og andre godkendere.
• I service/supportsystem, definere Release med links til projekt, CI's/CMDB og releasens Change-sag (beskrivelse, datoer mm.).
• Kommunikere til de rette brugere før en release, via Service Desk.
• Master-kopier af installerede software/pakker inklusive instruktioner og hardware-reservedele (lagres i DSL).
• Life cycle management af pakker og applikationer - fx udfastning af applikationer.
• Udrulle i værktøj til fjernadministration / deployment (fx Microsoft System Center Configuration Manager).
• Automatisere udrulninger => hurtigere udrulning med mindre risiko for menneskelige fejl.
• Rapportere på Release-processen.
• Løbende optimere Release-processen så kvalitet sikres og fejl minimeres.

Udfordringer

• Sikre test cases, testmiljø (særligt for de forretnings-kritiske systemer) og at testere er tilgængelige.
• Sikre opbakning til releasen fra brugere, forretningen og teknikere.
• Sikre at releaseprocedurer ikke omgås.
• Udrulning sker også på remote lokationer.

KPIer

Eksempler på Key Performance Indicators for Release Management:

• Antal Incidents forårsaget af nye Releases.
• Antal Releases rullet ud i produktion (efter IT-service, System).
• Succesrate - udrulninger totalt vs. tilbagerulninger (i pct.).
• Varighed pr. ny Release (timer) - fra klargøring til afslutning.
• Arbejdstid pr. ny Release (timer).
• Releases som overholder vs. ikke overholder Releaseplan (i pct.).
• Udrulningstype (automatisk, manuel).

Roller

Vigtige roller for Release Management-processen:

• Release Manager: Klargøre og pakke release. Kvalitetssikre før/efter release. Koordinere test.
• Change Manager: Ansvar for Change godkendelse og opdatering af CMDB.
• Test Manager: Udføre (regressions)test.
• Service Desk: Notifikation og involvering omkring Releases.
• Systemejer (defineres ad hoc)

Noter om Release Management

Release Management står for at udrulle bundter af Changes ind i IT-infrastrukturen på betryggende vis. Ideelt set forløber releasen efter et lineært forløb: Ændringen laves først i et udviklingsmiljø, den testes i et testmiljø og lanceres til sidst i produktionsmiljøet.

Releases kan ske på flere niveauer:

1. Full release hvor alle komponenter i et system frigives samlet. Fordel: Sikrer at alle ændringer er med. Risiko: Der er måske lavet ændringer som ligger udenfor releasen.
2. Del-release hvor kun ændrede CIs frigives. Fordel: Nem og hurtig frigivelse af ændringer. Risiko: Der er ikke 100% styr over hvad der er ændret fx i et softwaresystem.
3. Package release hvor software, hardware og/eller Changes frigives som en samlet pakke. Fordel: Brugerne forstyrres fx kun månedsvis eller kvartalsvis. Risiko: Teknikere husker ikke detaljerne omkring den Change, de lavede for 3 uger siden.

ITIL® is a registered trade mark of the Cabinet Office

Næste: Næste side: Service Desk »