Du har godkendelsesworkflows på indkøbsordrer over 5.000 kroner. Du har dimensionskontrol på finansposteringer. Du har opsætninger og valideringsregler i næsten alt hvad Business Central rører. Men når en udvikler skal udgive en ny version af jeres extension, så er processen tit en .app-fil, et håb og en fredag eftermiddag.
Jeg synes det er mærkeligt. Vi insisterer på kontrol og sporbarhed i alt hvad systemet gør, men den kode der driver systemet? Den flyver ind uden net.
Hvis man har en Business Central-løsning, så har man i princippet også en plan for hvordan man modtager opdateringer og får ændringer ind i systemet. Det er bare spørgsmålet om man aktivt har taget stilling til den plan eller om det bare kører på autopilot. Opdateringer kommer når de kommer, kode går ind når den er klar, og ingen har besluttet at det skal være sådan. Det er bare blevet sådan.
Det her handler om CI/CD (Continuous Integration og Continuous Deployment). Og inden du klikker videre fordi det lyder som et udviklertema, så bliv lige hængende. For det er mindst lige så meget et driftstema og et ledelsestema.
Hvad der faktisk går galt uden en pipeline
Lad mig tegne et billede de fleste genkender. En udvikler har lavet en rettelse. Den er testet manuelt, altså nogen har klikket rundt i Business Central og sagt “det ser fint ud” (hvilket i praksis betyder at de har testet det ene scenarie de lige har haft i hovedet). Rettelsen bliver publiceret til produktion en torsdag eftermiddag. Fredag morgen ringer en bruger og siger at lagerposteringerne ikke stemmer. Nu starter fejlsøgningen, og ingen er helt sikre på hvad der blev ændret, hvornår det blev ændret, eller om der var andre ændringer med i samme release.
Det scenarie er ikke ekstremt. Det er hverdag hos rigtig mange BC-partnere og deres kunder. Og problemet er ikke at folk er uansvarlige, det er at processen inviterer til fejl.
Automatiske tests: definer hvad “det virker” betyder
Den første og vigtigste ting en CI/CD-pipeline giver dig er, automatiske tests. Ikke fordi manuelle tests er dårlige, men fordi de er tilfældige. Manuelt tester man det man lige har ændret og måske de mest oplagte scenarier. Men hvad med den salgslinje der opfører sig anderledes når lokationskoden er sat til et lager med styret læg-på-plads? Hvad med det godkendelsesflow der bryder sammen når en dimension mangler? Den slags edge cases tester man ikke manuelt hver gang man udgiver en ny version. Det ville tage dage.
Med automatiske tests definerer du én gang hvad “det virker” betyder. Hvad skal salgslinjerne gøre? Hvad skal bogføringen validere? Hvad skal godkendelsesflowet håndtere? Og derefter kører de tests hver eneste gang nogen committer kode. Ikke når nogen husker det. Ikke når der er tid. Hver gang.
I min optik er det den mest undervurderede gevinst ved CI/CD. Det tvinger jer til at formulere hvad I forventer af jeres løsning, og det alene er ofte en øjenåbner. Jeg har set teams der først da de skulle skrive tests opdagede at de ikke var enige om hvad den korrekte adfærd var for en given proces. Den diskussion er værd at tage, og jo før den kommer, jo bedre.
Versionsstyring: ved hvad der ændrede sig, og hvornår
Versionsstyring med Git (eller et tilsvarende system) lyder måske basalt, men det er forbløffende hvor mange BC-løsninger der stadig lever uden det. Uden versionsstyring er historikken væk. Du kan ikke se hvad der blev ændret mellem version 1.4 og 1.5. Du kan ikke rulle tilbage hvis noget går galt. Du kan ikke se hvem der ændrede hvad. Det er som at bogføre uden bilag, teknisk set kan man godt, men man ender med at fortryde det (og det gør man typisk en fredag eftermiddag).
Med versionsstyring har du et komplet spor. Hver ændring er dokumenteret med en besked der forklarer hvorfor den blev lavet. Hvis noget går galt i produktion, kan du sammenligne den nuværende version med den forrige og finde præcis hvad der er anderledes. Det tager minutter i stedet for timer.
Og så er der den del de fleste overser: versionsstyring gør det muligt at arbejde parallelt uden at træde hinanden over tæerne. To udviklere kan arbejde på hver deres feature uden at overskrive hinandens kode. Det lyder selvfølgeligt, men prøv at spørge et team der deler et udviklingsmiljø uden branching hvordan de koordinerer. Svaret involverer typisk et whiteboard og en stor del held.
Bedre kontrol af kode: pull requests og code review
Versionsstyring alene giver dig historik. Men kombineret med pull requests giver det dig kontrol over hvad der overhovedet kommer ind i løsningen. En pull request er i bund og grund en anmodning: “Jeg har lavet disse ændringer, vil du kigge dem igennem før de bliver en del af produktionskoden?”
Det betyder at ingen kode glider ind ubemærket. En anden udvikler, en lead arkitekt eller en konsulent der kender forretningslogikken, kigger ændringerne igennem inden de bliver flettet ind. Det fanger fejl, ja, men det fanger også misforståelser. “Vent, den her ændring fjerner valideringen på dimensionskoden. Var det meningen?” Den slags spørgsmål dukker op i code reviews, og de er guld værd.
Jeg ser det som den digitale version af fire-øjne-princippet. Vi kræver det ved betalinger i banken. Vi kræver det ved godkendelse af indkøb. Men kode der styrer lagerbevægelser, bogføring og salgsfakturering? Den har vi ikke altid de samme krav til. Det giver ikke mening.
Releases uden for arbejdstiden: pipelinen bliver ikke træt
Den sidste brik er timing. Når du har automatiske tests og versionsstyring på plads, kan du lade din pipeline håndtere selve udrulningen, og den behøver ikke ske klokken 14 en torsdag.
En pipeline kan bygge din app, køre alle tests, og hvis alt er grønt, publicere den nye version klokken 02 om natten. Ingen sidder og venter, ingen glemmer et trin, og ingen bliver stresset fordi de skal nå det inden frokost. Om morgenen ligger den nye version klar, og hvis noget fejlede undervejs, står det i loggen.
Det er ikke bare bekvemmelighed. Det er risikostyring. Releases i arbejdstiden skaber forstyrrelser, brugere der pludselig bliver bedt om at lukke deres BC, supporthenvendelser der kommer ind mens teamet stadig er midt i udrulningen, og det uundgåelige tidspres der gør at man springer “de sidste par tests” over fordi klokken er blevet mange.
Med nattelige releases har teamet hele næste morgen til at verificere at alt ser rigtigt ud inden brugerne for alvor går i gang. Og hvis noget er galt, kan de rulle tilbage inden det påvirker driften. Den ro er svær at sætte en pris på, men alle der har prøvet et fredag-eftermiddag-deploy-der-gik-galt kender værdien.
Det handler om den samme disciplin
Mit take er at CI/CD for Business Central ikke handler om at være en moderne udviklerbutik. Det handler om at behandle sin kode med den samme respekt og disciplin som man behandler alt andet i systemet.
Du ville ikke lade nogen bogføre direkte i finansmodulet uden validering. Du ville ikke lade en lagermedarbejder flytte varer uden at registrere det. Hvorfor skulle du så lade kode gå i produktion uden at den er testet automatisk, versioneret og gennemgået af et andet par øjne?
Og man behøver ikke starte med det hele på én gang. Noget af det nemmeste er at tage kontrol over hvornår I modtager opdateringer fra Microsoft, at jeres BC fx. kun opdateres når I er klar til det, ikke bare når Microsoft trykker på knappen. Det alene er et kæmpe skridt fra autopilot til bevidst styring. Derfra er vejen til en fuld CI/CD-pipeline med automatiske tests, code review og nattelige releases kortere end man tror.
GitHub Actions eller lignende værktøjer kan have en grundlæggende pipeline kørende på en dag eller to (ja, virkelig). Den svære del er ikke teknologien. Den svære del er beslutningen om at man vil have styr på det. Resten er bare opsætning.
