Endring, versjonering og utfasingspraksis

Kontrollert endring som gjør at kunder slutter å lage kopier.

Endring er normalen

Uten en tydelig praksis for endring skjer to ting:

• konsumenter lager kopier “for sikkerhets skyld”
• produktflater blir vanskeligere å forbedre fordi alle endringer oppleves som risikable

Målet med dette kapittelet er å gjøre endring forutsigbart uten å gjøre det tungt: tydelige definisjoner, en enkel versjonslogikk og en ryddig måte å fase ut på.

Hva er en breaking change i et dataprodukt?

I dataprodukter er “breaking” ofte mer enn et kolonnenavn som endrer seg. Den største risikoen er stille feilbruk: at alt fortsatt kjører, men gir andre tall.

Definer breaking change bredt, men med konkrete eksempler, ellers ender alle endringer opp i en grå sone.

Typiske breaking endringer

En endring bør behandles som breaking når den kan få konsumenter til å feile, eller til å gi feil resultat uten at de merker det. Vanlige kategorier:

• Semantikk: dere endrer betydningen av et felt, en KPI, eller en definisjon (“aktiv kunde”, “omsetning”, “ordrestatus”)
• Keys og kardinalitet: join keys endres, eller forholdet endres (1–1 blir 1–mange)
• Granularitet: dere går fra ordrelinje til ordre, eller fra dag til time, uten at det er eksplisitt
• Tidslogikk: endring i hva “gyldig nå” betyr, historikkmodell, eller hvordan perioder håndteres
• Filtrering og scope: nye eksklusjoner/inkluderinger som endrer populasjonen (f.eks. testordre, interne kunder, “kun betalte ordre”)
• Tilgang og policy: en endring i tilgangsstyring som gjør at konsumenter mister tilgang eller får nye begrensninger

Skjemaendringer kan også være breaking (kolonner fjernes, datatype endres), men i dataprodukter er det semantikken som er det farligste.

Ikke-breaking endringer

Det motsatte bør også være tydelig: endringer som normalt ikke trenger stor prosess, men fortsatt bør loggføres.

Eksempler:

• nye kolonner som er additive og tydelig dokumentert
• ytelsesforbedringer i motorrommet uten endring i produktflaten
• bugfix som gjør produktet mer korrekt, uten at løftet endres (men: dette kan fortsatt kreve kommunikasjon hvis tall endrer seg)

Versjonering: bruk SemVer som språk

Versjonering handler om å ha et felles språk for konsekvens. SemVer fungerer fordi alle kjenner mønsteret.

• MAJOR: breaking endring i produktflaten (konsumenter må gjøre noe)
• MINOR: bakoverkompatibel utvidelse (konsumenter kan velge å ta i bruk)
• PATCH: retting/justering uten endring i løftet som gis

Det viktigste er konsistens: at dere bruker dette språket når dere kommuniserer endringer.

Hvor skal versjonen “bo”?

Velg ett primært sted. To steder holder:

• versjon + changelog på produktsiden (katalog/README)
• eventuelt en enkel product_version i metadata, hvis dere har et standardfelt eller descriptor

En konsument skal kunne finne “hva er siste versjon, og hva endret seg” uten å måtte spørre noen. Se I praksis: produktside, katalog og komponenter for hva produktsiden bør inneholde.

Endringspolicy: varsling, overgang og målrettet kommunikasjon

En god endringspolicy gjør det enklere å forbedre produktet fordi den reduserer frykten hos konsumentene. Den trenger ikke være lang, men den må være tydelig på tre ting.

Når dere skal gjøre en breaking change, må dere vite hvem som blir påvirket. Det henger tett sammen med praksisen fra tidligere kapitler: navngitte kunder/konsumentmiljøer og synlig bruk.

Standardiser:

• hvor dere varsler (én kanal + lenke til changelog)
• hvem som får varsel (navngitte konsumentmiljøer / eierteam)
• når dere varsler (minimumsfrist som passer nivået på produktet)

Overgang: parallelle flater der det trengs

Ved breaking endringer bør dere som hovedregel tilby en overgangsperiode der gammel og ny flate lever parallelt, med tydelig dato for utfasing:

• product_v1 lever videre en periode
• product_v2 introduseres med migreringsnotat
• dere måler adopsjon og følger opp de som henger igjen

Migreringsnotat: kort og konkret

Et migreringsnotat bør svare på:

• hva endrer seg (semantikk, keys, tidslogikk, scope)
• hva må konsumenten gjøre (SQL-eksempel eller konkret handling)
• hva er fristen, og hva er erstatningen

Blir notatet langt, er det som regel et signal om at endringen burde vært delt opp.

Utfasing

Utfasing er ikke bare opprydding. Det er en del av produktarbeidet, fordi porteføljen ellers vokser uten at signalverdien gjør det.

En god utfasing gjør tre ting:

• reduserer run cost
• gjør katalogen mer troverdig
• gir rom til å forbedre produktflater uten å bære all historikk for alltid

Når et dataprodukt (eller en produktflate/versjon) skal fases ut, bør produktsiden alltid ha:

• tydelig status: “utfases”
• frist: dato for når det ikke lenger er støttet
• anbefalt erstatning (ny flate eller annet produkt)
• hva som skjer etter fristen (stopp/degrader/slett – vær konkret)
• lenke til migreringsnotat og changelog

Skill mellom:

• Utfases: produktflaten er fortsatt tilgjengelig, men anbefales ikke. Dere støtter den kun i en overgangsperiode.
• Avviklet: produktflaten skal bort eller nedgraderes til komponent.

Dette henger direkte sammen med livsløpsstatusene “utfases” og “avviklet” fra porteføljestyringen i kapittel 2. Det gjør porteføljen lettere å forstå: “trygt å bygge på” vs “på vei ut”.

Hvordan dette henger sammen med produkt vs komponent

Praksis for endring og utfasing er en av de tydeligste forskjellene på dataprodukt og komponent.

• En komponent kan endres oftere, og endring skjer mer internt.
• Et dataprodukt har en produktflate som andre bygger på. Da må endringer behandles som endringer i et grensesnitt: varsling, overgang og tydelig historikk.

Har dere ikke kapasitet til dette, er det helt greit å la det være komponent. Det gir lavere forventninger, mindre risiko for misforståelser og mindre “støy” i katalogen.

Neste steg er å se hvordan dette fungerer i praksis over tid: Produktforum, de første 100 dagene og hva vi har lært.