Derfor skal du kreve skikkelige testmiljøer og ryddige releaser
Krev at endringer aldri går rett ut i produksjon. En profesjonell releaseprosess har en miljøtrapp med utvikling, test og produksjon, der hver endring verifiseres i et testmiljø før den slippes. Du skal ha rett til å godkjenne før release, og det skal være mulig å rulle tilbake en dårlig release raskt og uten panikk.
Spørsmålet høres teknisk ut, men er i bunn og grunn et risikospørsmål som du som kunde bør bry deg om: Hvordan kommer en endring fra utviklerens tastatur og ut til kundene dine? Hvis svaret er «direkte», har du et problem, uansett hvor dyktige utviklerne er. Slik ser en ryddig releaseprosess ut, forklart uten devops-sjargong.
Miljøtrappen: utvikling, test, produksjon
Et profesjonelt oppsett har ikke bare ett miljø, men flere, og en endring vandrer oppover trappen før den når brukerne.
- Utvikling. Her bygger og tester utvikleren arbeidet sitt. At ting ikke virker, er normaltilstanden. Det er hele poenget med et verksted. Ingen kunder er i nærheten.
- Test (staging). Et miljø som er bygget for å ligne produksjon så mye som mulig, gjerne med realistiske data. Her verifiseres det at endringen fungerer i noe som oppfører seg som produksjon. Det er siste stopp før release.
- Produksjon. Miljøet som er i faktisk bruk, med virkelige brukere og reelle data. Hit skal bare det komme som allerede har vist seg å fungere ett trinn lenger ned.
Poenget med trappen er enkelt: å fange feil der de ikke koster noe. En feil i utvikling er et skuldertrekk. Den samme feilen i produksjon er en hendelse med berørte kunder. Hvert trinn oppover trappen er et filter, og jo mer testmiljøet ligner produksjon, desto mer finmasket blir det.
Retten din til å verifisere før release
Som kunde skal du ikke måtte stole blindt på at en endring er riktig. Du skal ha rett til å se den i et testmiljø og si ja før den går i produksjon.
Det er særlig viktig for det som påvirker hvordan virksomheten din eller kundene dine opplever tjenesten: en ny brukerflyt, en endret prislogikk, et omarbeidet skjema. Å klikke seg gjennom det i staging tar minutter og avslører misforståelser som ellers først merkes når kundene allerede er rammet. Krev at den muligheten finnes, og bruk den til alt som er forretningskritisk.
En sunn prosess gjør dette kontrollpunktet til en selvfølge, ikke til en tjeneste man må be om. Hvis leverandøren synes at gjennomgangen din står i veien, er det i seg selv et signal som er verdt å merke seg.
Et scenario: fredagsfiksen
En liten endring skal ut sent en fredag: bare en justert tekst på betalingssiden, «ufarlig». Uten miljøtrapp går den rett i produksjon. Justeringen ødelegger tilfeldigvis knappen ved siden av, og betalingen slutter å fungere. Ingen merker det før e-postene fra kundene begynner å tikke inn i løpet av helgen, og først på mandag er det noen som kan rette feilen.
Med en ryddig prosess ville den samme endringen ha passert staging, der et raskt klikk ville ha avslørt den ødelagte knappen før en eneste kunde så den. Og selv om noe likevel hadde sluppet gjennom, ville en rollback ha tatt produksjonen tilbake til den fungerende versjonen på minutter. Det er sjelden de store, planlagte releasene som skaper problemer. Det er den lille «ufarlige» fiksen uten rutine.
Rollback: kravet om å kunne rulle tilbake raskt
Selv med testmiljøer vil en dårlig release før eller siden slippe gjennom. Forskjellen på en rotete kveld og en katastrofe er om det er mulig å rulle tilbake.
Rollback er evnen til å gå raskt tilbake til forrige fungerende versjon. Med den blir en feil i produksjon en kontrollert tilbakerulling: trykk tilbake, pust ut, feilsøk i ro og mak. Uten den blir den samme feilen en stresset jakt på en akutt løsning mens brukerne sitter fast i det som ikke virker.
| Krav | Hva det gir deg |
|---|---|
| Miljøtrapp | Feil fanges i test i stedet for hos kundene |
| Verifisering før release | Rett til å godkjenne forretningskritiske endringer på forhånd |
| Rask rollback | En dårlig release blir en tilbakerulling, ikke en krise |
Krev at rollback er en selvfølgelig del av prosessen, ikke noe man improviserer midt i en hendelse. Spørsmålet du bør stille, er rett frem: «Hvis en release går galt, hvor raskt er vi tilbake på forrige versjon?» Et trygt svar måles i minutter.
Slik bruker du dette
Du trenger ikke å forstå hvordan releaser gjennomføres teknisk. Du må stille tre spørsmål før du signerer: Går endringer via et testmiljø før produksjon? Får vi verifisere det som er forretningskritisk, før release? Og hvor raskt kan en dårlig release rulles tilbake? Svarene viser med én gang om releasehåndteringen er gjennomtenkt eller skjer på lykke og fromme.
Vi i Weapp bygger denne disiplinen inn i systemarbeidet fra start, for det er billigere å ha den på plass tidlig enn å innføre den etter det første havariet. Ta kontakt, så forteller vi hvordan en ryddig releaseflyt kan se ut for dere.
Ofte stilte spørsmål
Hva er forskjellen på testmiljø og produksjon?
Produksjon er miljøet som er i faktisk bruk, der de virkelige brukerne og de reelle dataene finnes. Et testmiljø er en kopi der endringer kan prøves ut uten at noen kunde blir berørt. Poenget er å fange feil der de ikke koster noe. En endring som er testet og godkjent i et miljø som ligner produksjon, har mye lavere risiko når den først slippes i produksjon.
Hva menes med staging?
Staging er et testmiljø som er bygget for å ligne produksjon så mye som mulig, med samme oppsett og gjerne med realistiske data. Det er siste stopp før en endring går i produksjon. Jo mer staging ligner produksjonsmiljøet, desto større er sjansen for at feil oppdages der i stedet for hos brukerne etter release.
Hva er rollback, og hvorfor er det et krav?
Rollback er evnen til å gå raskt tilbake til forrige fungerende versjon når en release viser seg å være dårlig. Uten den blir en feil i produksjon en stresset jakt på en akutt løsning mens brukerne rammes. Med den blir den samme feilen en kontrollert tilbakerulling på minutter. Krev at det alltid er mulig å rulle tilbake en release raskt.
Kan man ikke bare teste direkte i produksjon?
Det gjøres, men da bruker man kundene som forsøkskaniner. En feil som ville ha blitt fanget i et testmiljø, rammer i stedet virkelige brukere, reelle data og omdømmet til virksomheten. Enkelte små rettelser kan føles ufarlige å sende rett ut, men det er nettopp den vanen som før eller senere slipper gjennom feilen som gjør reell skade.
Må også små endringer gå gjennom miljøtrappen?
Ja, som prinsipp. De aller fleste alvorlige driftsforstyrrelser kommer fra en endring som noen vurderte som liten og ufarlig, og som derfor fikk gå utenom rutinen. En ryddig prosess betyr at den samme veien gjelder uansett hvor triviell endringen ser ut. Beskyttelsen ligger i at alt går samme vei, ikke i å gjøre unntak for det som virker enkelt.