Derfor skal du kræve rigtige testmiljøer og ordnet release management
Kræv at ændringer aldrig går direkte ud i produktion. En professionel releaseproces har en miljøtrappe med udvikling, test og produktion, hvor hver ændring verificeres i et testmiljø før den frigives. Du skal have ret til at godkende før release, og det skal være muligt hurtigt at rulle en dårlig release tilbage uden panik.
Spørgsmålet lyder teknisk, men er grundlæggende et risikospørgsmål du som kunde bør gå op i: Hvordan kommer en ændring fra en udviklers tastatur ud til dine kunder? Hvis svaret er “direkte”, har du et problem uanset hvor dygtige udviklerne er. Sådan ser en ordnet releaseproces ud, forklaret uden devops-jargon.
Miljøtrappen: udvikling, test, produktion
En professionel opsætning har ikke ét enkelt miljø, men flere, og en ændring bevæger sig op ad trappen før den når brugerne.
- Udvikling. Her bygger og afprøver udvikleren sit arbejde. At noget er i stykker, er normaltilstanden: Det er hele pointen med et værksted. Ingen kunder er i nærheden.
- Test (staging). Et miljø der er bygget til at ligne produktion så tæt som muligt, gerne med realistiske data. Her verificeres det at ændringen virker i noget der opfører sig som den virkelige verden. Det er sidste stop før release.
- Produktion. Det skarpe miljø med rigtige brugere og rigtige data. Herop skal kun det der allerede har vist sig at virke et trin længere nede.
Idéen med trappen er enkel: Fang fejl der hvor de ikke koster noget. En fejl i udvikling er et skuldertræk. Samme fejl i produktion er en hændelse med berørte kunder. Hvert trin op ad trappen er et filter, og jo mere testmiljøet ligner produktion, desto mere finmasket bliver det.
Din ret til at verificere før release
Som kunde skal du ikke være nødt til at stole blindt på at en ændring er rigtig. Du skal have ret til at se den i et testmiljø og sige ja før den går live.
Det er særligt vigtigt for det der påvirker hvordan din forretning eller dine kunder oplever tjenesten: et nyt flow, en ændret prislogik, en omlavet formular. At klikke det igennem i staging tager minutter og afslører misforståelser som ellers først bliver opdaget når kunderne allerede er ramt. Kræv at den mulighed findes, og brug den til alt der er forretningskritisk.
En sund proces gør dette kontrolpunkt til en selvfølge, ikke til en tjeneste man beder om. Hvis leverandøren synes at din gennemgang er i vejen, er det i sig selv et signal der er værd at notere.
Et scenarie: fredagsrettelsen
En lille ændring skal ud sent en fredag: bare en justeret tekst på betalingssiden, “harmløst”. Uden miljøtrappe går den direkte i produktion. Justeringen kommer til at ødelægge knappen ved siden af, og betalingen holder op med at virke. Ingen opdager det før kundemails begynder at tikke ind i løbet af weekenden, og først mandag er der nogen der kan rette det.
Med en ordnet proces var samme ændring gået gennem staging, hvor et hurtigt klik havde afsløret den ødelagte knap før en eneste kunde så den. Og selv hvis noget alligevel var sluppet igennem, havde en rollback bragt produktionen tilbage til den fungerende version på minutter. Det er sjældent de store, planlagte releases der skaber problemer. Det er den lille “harmløse” rettelse uden rutine.
Rollback: kravet om at kunne rulle hurtigt tilbage
Selv med testmiljøer vil en dårlig release på et tidspunkt smutte igennem. Forskellen på en hektisk aften og en katastrofe er om det er muligt at rulle tilbage.
Rollback er evnen til hurtigt at vende tilbage til den forrige fungerende version. Med den bliver en fejl i produktion en kontrolleret tilbagerulning: tryk tilbage, pust ud, fejlsøg i ro og mag. Uden den bliver samme fejl en stresset jagt på en akut løsning mens brugerne sidder fast i det der ikke virker.
| Krav | Hvad det giver dig |
|---|---|
| Miljøtrappe | Fejl fanges i test i stedet for hos kunderne |
| Verificering før release | Ret til at godkende forretningskritiske ændringer på forhånd |
| Hurtig rollback | En dårlig release bliver en tilbagerulning, ikke en krise |
Kræv at rollback er en selvfølgelig del af processen, ikke noget man improviserer midt i en hændelse. Spørgsmålet der skal stilles, er ligetil: “Hvis en release går galt, hvor hurtigt er vi så tilbage på den forrige version?” Et betryggende svar måles i minutter.
Sådan bruger du det her
Du behøver ikke forstå hvordan releases foregår teknisk. Du skal stille tre spørgsmål før du skriver under: Går ændringer via et testmiljø før produktion? Må vi verificere det forretningskritiske før release? Og hvor hurtigt kan en dårlig release rulles tilbage? Svarene viser med det samme om release management er gennemtænkt eller sker på lykke og fromme.
Vi i Weapp bygger denne disciplin ind i systemarbejdet fra start, for den er billigere at have fra begyndelsen end at indføre efter det første sammenbrud. Kontakt os, så fortæller vi hvordan et ordnet releaseflow kan se ud for jer.
Ofte stillede spørgsmål
Hvad er forskellen på testmiljø og produktion?
Produktion er det skarpe miljø hvor rigtige brugere og rigtige data findes. Et testmiljø er en kopi hvor ændringer kan afprøves uden at nogen kunde påvirkes. Pointen er at fange fejl der hvor de ikke koster noget. En ændring der er testet og godkendt i et miljø som ligner produktion, har en langt lavere risiko når den først går live.
Hvad menes der med staging?
Staging er et testmiljø der er bygget til at ligne produktion så tæt som muligt: samme opsætning, gerne med realistiske data. Det er sidste stop før en ændring går live. Jo mere staging ligner det rigtige miljø, desto større er chancen for at fejl opdages der i stedet for hos brugerne efter release.
Hvad er rollback, og hvorfor er det et krav?
Rollback er evnen til hurtigt at gå tilbage til den forrige fungerende version når en release viser sig at være dårlig. Uden den bliver en fejl i produktion en stresset jagt på en akut løsning mens brugerne rammes. Med den bliver samme fejl en kontrolleret tilbagerulning på minutter. Kræv at en release altid hurtigt kan rulles tilbage.
Kan man ikke bare teste direkte i produktion?
Det bliver gjort, men så bruger man kunderne som forsøgskaniner. En fejl som ville være blevet fanget i et testmiljø, rammer i stedet rigtige brugere, rigtige data og jeres omdømme. Enkelte små rettelser kan føles harmløse at skyde direkte ud, men det er netop den vane der før eller siden lukker den fejl igennem som gør virkelig skade.
Skal selv små ændringer igennem miljøtrappen?
Ja, som princip. Langt de fleste alvorlige driftsforstyrrelser kommer fra en ændring som nogen vurderede som lille og harmløs og derfor lod gå uden om rutinen. En ordnet proces betyder at samme vej gælder uanset hvor triviel ændringen ser ud. Det er ensartetheden der giver beskyttelsen, ikke at man gør undtagelser for det der virker enkelt.