Kom i gang med DataOps

De siste årene har Continuous Integration/Continuous Deployment (CI/CD) pipelines blitt vanlig i applikasjonsutvikling. Prinsippene for CI/CD i applikasjonsutvikling er enkle; kode skal være versjonshåndtert og endringer utvikles på egne feature-brancher. Koden inneholder tester, som kjøres automatisk ved hjelp av en byggløsning før endringene merges til produksjonsbranchen. Datavarehus har hengt etter denne utviklingen.

Av: Henning Holgersen, analyseekspert i Webstep

Noen hevder at ETL-utvikling ligger 10 år bak webutvikling med tanke på utviklerverktøy og utviklingsflyt. Samtidig er det er viktig å huske at applikasjonsutvikling er noe annet enn datavarehusutvikling, med andre muligheter og begrensninger. Det er derfor ikke alt i applikasjonsutvikling som er overførbart til datavarehus.

Likevel er det mye inspirasjon som kan hentes fra moderne applikasjonsutvikling. Uansett hvilken løsning dere har i dag og hvilke planer dere har for fremtiden, er det ting dere kan gjøre for å delautomatisere løpet fra utvikling til produksjon. Her er fem konkrete tips;

1. Organiser testene

Mange utviklere har script som tester ulike antagelser i dataene. Alt fra tekniske begrensninger som unikhet og not-null skranker, til forretningslogikk og kontroller for at tabeller ikke blir tomme kan det allerede finnes tester for. Disse kan være gjemt rundt på C-disker hos utviklere.

Slike tester blir ofte betegnet som regresjonstester. De skal sikre at ingenting går bakover – at vi ikke reintroduserer feil som allerede har blitt fikset.

Tester er mye mer nyttig når de er tilgjengelig for andre, og det reduserer personavhengigheten. Hvis dere samler og organiserer de på ett sted, blir de til et felles sett med akseptanse- og enhetstester som alle kan benytte seg av og bidra til. Ingen utvikling er ferdig før testene er passert.

For at et slikt testregime skal være gjennomførbart, er det viktig å ikke gape over for mye. Sørg for at testene kan kjøres etter at ETLen har kjørt. Selv om sammenligninger før og etter last er verdifullt, øker det kompleksiteten voldsomt. Start enkelt, og sørg for at det beste ikke blir det godes verste fiende. Bli også enig om en felles standard for output. Min anbefaling er å skrive tester i form av SQL-spørringer som returnerer null rader dersom testen passerer, og én eller flere rader dersom testen feiler. På den måten blir det også veldig enkelt å dokumentere og sjekke at testene er passert.

2. Gjenbruk testene i produksjon

De samme testene som sjekker for feil i utvikling kan også oppdage feil i produksjon. Endringer i kilden eller feil i kjøringen kan skape feil i data for brukerne, og det er mye bedre om vi selv oppdager feilene før brukerne melder fra. For dette formålet kan testene også utvides til å fokusere mer på kildedata, siden mange feil i produksjon stammer fra feil i kilden.

3. Velg ETL-verktøy med god git-integrasjon

CI-arbeidsflyter er normalt sentrert rundt Git. Ikke fordi Git i seg selv er en nødvendighet for CI, men fordi versjonshåndtering er verdifullt i sin egen rett. Dessuten er Git det suverent mest populære versjonshåndteringsverktøyet, og Git er også det naturlige stedet å legge CI for de som først bruker Git.

På grunn av at både Git og CI er så populært, finnes det veldig mange CI-verktøy som bygger på Git. Fellesnevneren er at en forhåndsdefinert jobb starter når endringene som utvikles merges inn i produksjonsbranchen – helst gjennom en pull-request. Derfor er det viktig at du velger ETL verktøy som ikke bare har git-integrasjon, men også har en git-integrasjon som spiller på lag med CI-verktøyet. ETL-verktøyet bør ha støtte for pull-requests som en naturlig del av arbeidsflyten for produksjonssetting. Dette kan høres veldig selvfølgelig ut for applikasjonsutviklere, men ikke alle ETL-verktøy bruker git på en måte som er forenlig med CI-arbeidsflyter.

Om Git og pull-requests ikke er aktuelt for dere nå, er det likevel mulig å bruke CI-arbeidsflyter ved f.eks. å integrere de i Jira. Jira kan konfigureres til å sette i gang CI-arbeidsflyter som et ledd av arbeidsflyten. Så lenge Jira har nok informasjon til å starte riktig jobb basert på innholdet i saken, kan dette være en farbar vei for CI uten Git.

4. Sjekk kodekvaliteten

Applikasjonsutviklere har ofte egne standarder for kodestil, som hjelper med å gjøre koden lesbar og reduserer sannsynligheten for feil ved å oppdage uheldige mønstre. Om dere skriver egen SQL kan denne sjekkes automatisk. Å legge til kodekvalitet som en sjekk er veldig enkelt når dere allerede bruker Git og har en byggløsning. Det finnes allerede biblioteker som gjør denne kontrollen, og som kan kjøres ved hjelp av en enkel kommando.

5. Automatiser avhengighetssjekker

Endringene dere gjør på tabell A kan ha store konsekvenser for tabell B, selv om endringene isolert sett er nødvendige og kurante. Du kan aldri vite sikkert hvilke avhengigheter andre har mot dine tabeller, og hvilke antagelser disse hviler på. Når alle prosjekt har tester og et CI-system som automatisk kjører ETL på pull-request, er mesteparten av brikkene på plass for at dere også kan kjøre ETL eller tester fra andre deler av datavarehuset. På den måten er det mulig å oppdage om endringene deres bryter nedstrøms avhengigheter.

Den gjenstående brikken er å finne alle nedstrøms avhengighetene slik at dere vet hva som skal testes. Dette kan gjøres automatisk ved å analysere ETLen eller gjenbruke eksisterende metadata, men i et stort datavarehus kan dette være vanskelig. Et alternativ kan være å manuelt definere de avhengighetene det er viktig å teste.

Om endringene fører til at nedstrøms-prosesser feiler eller gir feil i data, er det god grunn til å avvente produksjonssettingen.

Datakvalitet avgjørende

Tips er bare gode idéer, og det er ikke sikkert det passer å implementere alt. Og kanskje er det heller ikke nødvendig.

Å samle tester er likevel nyttig selv om dere kjører de manuelt og ad-hoc. På samme måte trenger ikke sjekk av kodestil å være noe som gjøres automatisk i en CI/CD prosess. Det har selvfølgelig en verdi også om det gjøres manuelt. Automatiserte prosesser er praktisk, men målet er at koden er god og lesbar for den neste utvikleren – og det krever ikke automatisering.

Verktøy med god git-integrasjon og avhengighetssjekker mellom tabeller kan kanskje være vanskeligere å gjennomføre inkrementelt, men de er ikke nødvendigvis avhengige av hverandre.

Til slutt må dere ha et bevisst forhold til hvilke data dere bruker i utvikling. Gode tester er lite verdt hvis datakvaliteten er for dårlig – eller for god. Det er i utvikling dere ønsker å finne feilene, men hvis testdataene dere bruker ikke inneholder hjørnetilfeller eller vanlige feil som finnes i produksjonsdata, kommer brukere til å finne feil som dere ikke hadde mulighet til å ta høyde for i utviklingen.

God datakvalitet er avgjørende for brukerne. Like viktig er testdata, som har en direkte innvirkning på datakvaliteten i produksjonen.

Kom i gang

Innsikt og analyse er et viktig satsingsområde for både Webstep og våre kunder. Ta kontakt med din Webstep-kontakt eller ring Mathias Karthum om du ønsker å komme raskt i gang med å avdekke verdiskapende innsikt for din virksomhet – eller har lyst til å jobbe i et av Norges ledende fagmiljøer på dataanalyse.