Endring, versjonering og utfasingspraksis

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

Endring er normalen

Hvis dere ikke har en tydelig praksis for endring, skjer to ting ganske forutsigbart:

• 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.

Derfor er det nyttig å definere breaking change bredt, men med konkrete eksempler.

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 ofte semantikken som er det farlige.

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 først og fremst om å ha et felles språk for konsekvens. SemVer er nyttig fordi alle kjenner mønsteret.

Enkel SemVer-praksis kan være:

• 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 faktisk bruker dette språket når dere kommuniserer endringer.

Hvor skal versjonen “bo”?

Velg ett primært sted. Typisk er dette nok:

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

Poenget er at en konsument skal kunne finne “hva er siste versjon, og hva endret seg” uten å måtte spørre noen.

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.

I praksis holder det å standardisere:

• 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.

Det trenger ikke være komplisert:

• 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 faktisk gjøre (SQL-eksempel eller konkret handling)
• hva er fristen, og hva er erstatningen

Hvis notatet blir langt, er det ofte 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

Det er nyttig å skille mellom:

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

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 det er normalt at 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.

Hvis dere ikke har 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.