Fra “Legacy” til nutiden

Jeg arbejder i dag som en del af Digital Media & Marketing-teamet hos BESTSELLER. Teamets primære produkt er DAM-systemet (Digital Asset Management), der vedligeholder og deler BESTSELLERs digitale aktiver på tværs af organisationen. Indimellem håndterer vi også andre produkter, der lander inden for “Media & Marketing”, men det er en historie til en anden gang.

Det største fokus har været at holde den tidligere DAM-løsning kørende, som var et COTS-system (Commercial Off-the-Shelf Software). Jeg identificerede hurtigt det presserende behov for et hurtigere og mere effektivt Digital Asset Management-system. Det kunne tage over et døgn, før ny-uploadede aktiver dukkede op i systemet, og versionen af COTS-løsningen hos BESTSELLER var den sidste, der kunne køre on-prem. Det betød, at vi på sigt ville ramme problemer med ikke-understøttede operativsystemer eller andre sikkerhedshuller. Da adgangen til højopløselige produktbilleder er essentiel for vores onlinehandel, gik jeg i gang med at skabe et erstatningssystem kaldet “StorM” (Store Media).

Som en integreret del af udviklingsteamet spillede jeg en central rolle i at udtænke en migrationsplan væk fra det gamle system. Det blev gjort med stor omhu for at minimere smertepunkter for både de nuværende brugere og de integrerede systemer. Ved at anvende sprog og rammer som C#, .NET 6 -> 8, Typescript, React og Next.js lykkedes det os (det her kunne jeg ikke have gjort alene!) at skabe et system, der ydede markant bedre end forgængeren, samtidig med at vi styrkede system-til-system-integration gennem bedre datakontrol og datakvalitet.

Grundlæggende forbedringer, såsom bedre applikationsstabilitet, kom via indsigter i telemetridata, så fejl faktisk kunne udbedres. Det gjorde vi blandt andet ved at bygge et logging/monitoreringsbibliotek til deling på tværs af .NET-projekter, som alle tech-teams i BESTSELLER kan bruge. Biblioteket hjalp migreringen fra loggingplatforme som Graylog og Datadog videre til ELK-stacken og gav dermed hurtigere fejldiagnoser. Senest er vi flyttet mod en OpenTelemetry-centreret løsning, som løsriver StorM yderligere fra specifikke telemetri-/monitoreringsleverandører.

Værktøjer og arbejdsgange

Når det gælder værktøjer, arbejder vi med et bredt udvalg af teknologier. De spænder fra C#, .NET, Typescript og React til backend-systemer, herunder Azure og Google Cloud Platform (GCP). Ved målrettet brug af Git og GitHub flyttede jeg teamets projekter fra Bitbucket og implementerede en Fork & Pull Request-arbejdsgang for at øge videndeling og kodekvalitet. Før det blev alt håndteret af eksterne konsulenter uden faste standarder for kodestil, arbejdsmetoder eller bare et simpelt tjek for fejl i commits.

Vores arbejdsgang blev yderligere styrket ved at automatisere vores build-pipeline med CircleCI og gå fra en manuel msbuild-proces til et NUKE-baseret build-script. Vi migrerede også fra en on-prem/hjemmebygget webhook-implementering til Azure EventGrid, hvilket forbedrede stabilitet og skalering samt gav bedre indblik og metrikker. Med StorM er alting automatiseret udrullet – via Terraform til IaC, GitHub Workflows/Actions og et par Bash-scripts.

Da jeg kom ind i teamet, prioriterede jeg at få alle til at bruge Confluence til dokumentation, så alt materiale lå nogenlunde samlet. Med erfaringer fra Coolblue kunne jeg anbefale gennemprøvede arbejdsgange.

MVP for API / EDI

Da COVID ramte, blev ressourcer knappe. Der opstod en idé om et generisk system til deling af produktdata, hvor alle BESTSELLERs produktdata kunne hentes fra ét sted. På en eller anden måde endte jeg som udvikler på projektet og byggede et MVP til en BESTSELLER-dækkende datadeling via API, EDI eller andre overførselsmetoder. Projektet er stadig i brug den dag i dag – nu ejet af et andet team, som jeg selv foreslog. Sådan et projekt kræver et stærkt team, så viden deles, og kritiske ting som monitorering og skalering bliver forankret i fællesskab.

Fortsat arbejde

Jeg er stadig hos BESTSELLER og presser hele tiden mig selv for at sikre, at StorM er så godt et system som muligt set i forhold til de ressourcer, vi har. Jeg er nu også arkitekt, hvilket betyder, at jeg bruger mere tid på BESTSELLER Tech-brede “regler” og best practices som en del af et arkitektfællesskab. Formålet er at løfte tech-kompetencerne i hele organisationen og skabe bedre alignment mellem teams, så data kan deles lettere og mere robust.