Overordna
- Vi er alle ansvarlege for at Cerebrum fungerer.
- Den/dei som utfører ei endring vert som hovudregel ansvarleg for å prodsette denne, og å følge den opp i ettertid. Det er desse som kjenner best til endringa.
- Alle fast tilsette i Cerebrum drift og Cerebrum utvikling har tilgang til å prodsette.
- Prodsettingar skal vere synlege for alle interessentar av Cerebrum, spesielt skal Cerebrum drift vere fortløpande oppdatert!
- Par-prodsetting: Ein skal alltid vere minst to personar på ei prodsetting ved kodeendringar. Dette for å redusere faren for feil.
- Det skal vere mulig å prodsette så ofte som mulig, så rutiner skal vere enkle, effektive og mest mulig automatiserte.
Kven prodsetter?
Både Cerebrum drift og Cerebrum utvikling skal kunne prodsette, uavhengig av kvarandre.
Cerebrum drift skal vere involvert i prodsettinga når det krever endringar i prodmiljøet utanom kode/konfig. I praksis betyr dette at Cerebrum utvikling kan berre prodsette når det er nok å bruke Cerebrum sine verktøy for å prodsette. Involvering av drift må vurderast frå sak til sak.
Tenester
Alle tenester som dette gjeld for:
- Cerebrum som køyrer i vanleg prodmiljø.
- Cerebrum sine nettenester, som Brukerinfo, Gløymd-passord-tenesta, passordtenesta og cweb.
- Bofh-klienter vi støtter.
Det er berre Cerebrum drift som kan prodsette for TSD, enn så lenge. Etter at denne rutina har satt seg kan vi vurdere å også inkludere TSD.
Varsel
Alle interessenter som vil bli påvirka av prodsettinga skal varslast på førehand dersom prodsettinga vil kreve over eitt minutt med nedetid, eller når det er ein risiko for at det kan skje! Nedetid på over ein time krever planlegging og varsel minst ei veke før.
Cerebrum-partnarar vert varsla på instansen si vanlege e-postliste, som går til RT. På UiO legg vi ut driftsmelding, og om nedetida er på over ein time må vi på førehand varsle på cerebrum-uio-varsel@usit.uio.no og legge ut planlagt endring og tjenesteavbrudd.
Informasjon
Tenestegruppa skal informerast om alle prodsettingar! Andre interessentar skal også kunne holde seg oppdaterte.
- Status skal sendast til instansen si e-postliste eller i RT, for alle prodsettingar. For Cerebrum-partnarane er e-post deira primære kanal for oppfølging.
- Alle prodsettingar skal loggast i Jira. Historikken skal vere lesbar for alle.
Jira
Deployeringssaker i Jira må kunne identifiserast og skillast frå andre saker. For å gjere dette bruker vi i første runde ein eigen label: "deployment". Dette kan endrast.
For brukarhistorier oppretter du sub-tasks for prodsettinga. For konfigendringar eller anna som er utanfor INT sine sprintar kan du opprette enkeltståande issues, men desse må eksistere i prosjektet CRB, sidan Cerebrum drift sitt Jira-prosjekt er nedsperra.
- Oversikt over alle fullførte prodsettingar.
- Oversikt over alle prodsettingar som ikkje har starta, eller som pågår.
Prodsettingssaker skal inneholde informasjonen:
- Kva skal bli prodsatt. Helst med lenker til Jira-saker, evt også RT-saker.
- Instansar den gjeld for.
- Status for prodsettinga. Venter den på prodsetting, pågår den eller er den fullført?
- Ved feil skal saka bli oppdatert med status og informasjon.
- Vart prodsettinga rulla tilbake? I så fall må saka gjenopnast.
- Vart feil fiksa? Kva er i så fall Jira-saka for fiksen, evt. setning om kva som vart gjort for å løyse det?
Det er viktig at Deployment-sakene er formulert og presentert så dei er lesbare for alle interessentar av Cerebrum. Ikkje alle er så veldig teknisk orienterte, og desse skal også kunne forstå kva som skjer.
Jira er nok ikkje det optimale verktøyet for dette behovet, så vi bør på sikt sjå på andre verktøy for å informere.
Rutine for prodsetting
Du må sikre deg at eventuelle avklaringar, merge-konflikter og eksterne avhengigheter er løyste før du starter på prodsettinga. Endringane bør ha vore testa i stagingmiljøet, når dette er på plass.
- Varsle (ved behov): Prodsettar varsler interessentar på førehand og vert enige om tidspunkt. Jira-saka opprettast i så fall no.
- Informere: Prodsetter informerer om at prodsettinga starter, både på e-post, i Jira og på XMPP.
- Mesteparten av dette kan automatiserast!
- Partnarane ønsker å få framheva saker som gjeld dei. Dette gjer vi ved å markere saker i Jira som er instans-spesifikke med ein eigen label med akronymet for instansen. Varselet vil då kunne inneholde ei framheving av saker som er spesielt relevante for ein instans.
- Forberede miljø: Den som skal prodsette gjer eventuelle endringar i miljøet og merger kode/konfig til master.
- Å dytte kode og konfig til master skal ikkje gjerast før prodsettinga starter. Vi skal ikkje ha kode i master som ikkje straks går i produksjon.
- Deployere: Prodsetter starter deployeringsverktøyet, sjå Teknisk om Cerebrum produksjonssetting for detaljar om korleis dette gjerast.
- Jira-saka skal få status til In progress, med kommentar om alle relevante parameter for prodsettinga, til dømes kva instans den gjeld, kva branch og kva som skal restartast i miljøet.
- Følge opp: Prodsettar ser over at alt køyrer som det skal, og utfører relevante testar.
- Jira-saka for prodsettinga settast til Done. Legg eventuelt inn kommentar med relevante detaljar.
- E-post sendast ut om at prodsettinga er fullført, eventuelt med meir detaljar om det feila.
- Ved feil, skal du fikse eller rulle tilbake? Hovudregelen er å fikse feilen, men er du i tvil, rull tilbake.
Prodsettaren har mulighet til å redigere saka manuelt før og etter, og kan til dømes legge inn kommentarar om kva som eventuelt feila i prodsettinga. Prodsettingsverktøyet bør utvidast til å gjere mykje av dette for prodsettaren automatisk, spesielt rundt e-postvarsel og oppdatering av Jira.
Merk: Rutina vil måtte oppdaterast etterkvart som vi får erfaring med den.
Etter prodsetting
Den som utførte endringa og prodsettinga må følge med på at endringa ikkje skapte problem for Cerebrum. Som regel i to dagar etter prodsetting, eller så lenge det er nødvendig.
- Sjå gjennom relevante feilmeldingar frå miljøet
- Sjekk at relevante Cerebrum-jobbar fullfører
- Høyr med interessent/bestillar om dei har testa endringa
Hugs at ei endring kan påvirke alle instansar på ulik vis! Ein fiks for UiO kan skape feil hos andre om ein ikkje held tunga beint i munnen.
Innføringsfase
Ny rutine for prodsetting i Cerebrum vart innført i slutten av 2015. Før sommaren 2016 skal vi vurdere om det skal vere ei permanent ordning at utviklarane har sjølv tilgang til å prodsette.
- Desember 2015: Vi starter med ny prodsettingsrutine, der utviklarane får prodsette sjølve
- Desember 2015: Cerebrum drift lærer opp alle i Cerebrum utvikling som skal ha prodsettingrettigheter.
- 1. januar 2016: Cerebrum utvikling er med på å prodsette. Utviklarar blir gitt tilgang til prod når dei har vore gjennom ei prodsetting med drift.
- 1. januar - 1. februar 2016: Alle prodsettingar skal gjerast med par-prodsetting, ved at ein frå drift ser på at ein frå utvikling prodsetter.
- Rundt 1. februar 2016: Cerebrum drift og utvikling vurderer om Cerebrum utvikling kan prodsette aleine.
- Før sommaren 2016: Tenestegruppa vurderer om ny prodsettingsrutine skal bli ei permanent ordning.
Enn så lenge alle prodsettingar skal skje i tett samarbeid med Cerebrum drift, må vi beholde Prodsettingskøa i Jira, for alle endringar som ikkje kan gå i prod omgåande. Denne avviklast når vi ikkje lenger bruker den.
Prodsettingsverktøyet mangler ein del automatikk. Dette kan både drift og utvikling bestille hos INT, så vert det eventuelt tatt med i ein av INT sine sprintar.
Vidare arbeid
Ny rutine er ute av pilot, så vi fortsetter med denne. Vi treng likevel å oppdatere og forenkle rutina etter erfaringane første halvåret.
Endringar er lov, men diskuter med tenestegruppa først.
Kva vi ser som må arbeidast med:
- Vi treng meir synlighet av kva som prodsettast, både internt og for interessentar.
- Skal vi kunne prodsette ofte, bør vi ha mykje meir overvåking av miljøa enn vi har i dag. Kva kan vi gjere her?
- Vi har ikkje adressert måling, dvs. å kunne måle at rutina er ei forbedring.