Når der arbejdes med tilpasninger i Business Central, er forskellen mellem sandbox og produktion ikke bare et spørgsmål om teknik. Det er selve rammen for, om ændringer bliver indført roligt og kontrolleret eller skaber fejl i den daglige drift.
Mange problemer opstår ikke, fordi koden er dårlig, men fordi miljøstrategien er uklar. En rettelse bliver testet på gamle data, en app-version springer et trin over, eller en ændring bliver publiceret direkte uden et fast releaseforløb. Det er netop her, en enkel og disciplineret model gør en stor forskel.
Et mønster, som ofte går igen i tekniske indlæg fra yzhums.com, hougaard.com, waldo.be og vjeko.com, er ret enkelt: hold udvikling, test og drift adskilt, arbejd med små releases, og sørg for at kunne se præcist, hvad der er ændret, hvornår og af hvem.
Hvad sandbox og produktion betyder i Business Central
Et sandbox environment i Business Central er et isoleret miljø til udvikling, test, debug, læring og afprøvning. Det påvirker ikke produktionsdata eller opsætning. Det fremgår af artiklen om sandbox environments på Learn. Produktion er derimod miljøet, hvor den virkelige drift foregår, og hvor stabilitet vægter højere end hastighed.
Det lyder banalt, men den praktiske konsekvens er vigtig: udvikling hører hjemme i sandbox. Produktion er ikke et sted, hvor man “lige prøver noget af”.
Når et miljø kopieres fra produktion til sandbox, bliver det nye miljø oprettet på samme application version som kildemiljøet, og installerede extensions følger med. Det gør en kopi velegnet til realistisk test, fordi data, opsætning og app-landskab ligner det, brugerne møder til daglig.
I praksis kan forskellen opsummeres sådan:
- Sikker udvikling og debugging
- Realistisk test af processer
- Drift med rigtige transaktioner
- Kontrolleret release til brugerne
- Fejlsøgning uden at ændre live-data
Miljøstrategi for Business Central med sandbox og produktion
En god miljøstrategi behøver ikke være tung. For mange virksomheder er det nok at tænke i tre lag: udvikling, validering og drift. Det kan godt ligge i få miljøer, hvis rollerne er klare.
En enkel model er ofte:
- En sandbox til udvikling og teknisk test.
- En sandbox til forretningstest og UAT.
- Et produktionsmiljø til den daglige drift.
I mindre opsætninger kan én sandbox dække begge testformål, men det kræver disciplin. Hvis udviklere og brugere tester i samme miljø, bliver det hurtigt uklart, hvilke data og hvilken kode der er gældende. Når fejl skal reproduceres, mister man sporbarhed.
Navngivning betyder mere, end mange regner med. Miljøer bør have faste navne som DEV, TEST og PROD eller tilsvarende. Samme princip gælder apps, pipelines og branches. Jo mindre tvivl der er om formålet med et miljø, desto lavere risiko er der ved deployment.
Hvis standardfunktioner skal vurderes bredt, kan hele standardpakken afprøves i sandbox ved at sætte Experience til Premium på Company Information. Det er nyttigt ved procesdesign og vurdering af funktioner, før der udvikles tilpasninger.
Versionsstyring og app-strategi i Business Central
Sikker flytning fra sandbox til produktion starter ikke ved selve deployment. Den starter i versionsstyringen.
AL-projekter bør ligge i et kildekodearkiv, typisk Git, med en fast branch-struktur. Mange vælger en hovedgren til releaseklar kode samt kortlivede feature branches til nye ændringer. Det gør det muligt at gennemgå, teste og rollbacke mere kontrolleret.
Det er en god idé at skelne tydeligt mellem extension-typer. Ifølge Learn om extension types and scope kan DEV-extensions kun eksistere i sandbox environments, mens Global apps kan findes i både sandbox og produktion. Det er en vigtig grænse. En udvikler kan godt publicere hurtigt til sandbox fra Visual Studio Code, men det er ikke den samme mekanik, som bruges til stabil drift.
Det bør omsættes til nogle faste regler:
- Kildekode: Alt ændres i versionsstyring før release
- Versionsnumre: Hver release får sit eget app-nummer
- Dependencies: Afhængigheder låses og testes samlet
- DEV-extensions: Bruges kun i sandbox
- Produktionsapps: Deployes som kontrollerede .app-pakker
Versionsnummeret er ikke kosmetik. Det er den mest enkle måde at se, hvad der er installeret hvor. Hvis sandbox kører 1.4.0.0 og produktion kører 1.3.2.0, skal det være tydeligt, hvilke ændringer forskellen dækker. Små spring er lettere at styre end store hop.
En praktisk regel er at udgive hyppigere, men i mindre bidder. Den tanke går igen hos flere erfarne Business Central-profiler: korte releaseintervaller giver mindre risiko, hurtigere fejlsøgning og mindre pres på brugerne.
Testforløb i sandbox før ændringer flyttes til produktion
Når en ændring er udviklet, bør den igennem mere end en enkelt kliktest. Sandbox er stedet, hvor både teknisk kvalitet og forretningsmæssig adfærd bliver kontrolleret.
Det første niveau er udviklertesten: kan appen publiceres, installeres og opgraderes uden fejl? Fungerer siden, tabellen, rapporten eller integrationen som tænkt? Kan en eksisterende opsætning bære ændringen?
Næste niveau er automatiseret test. Online sandboxes understøtter AL-tests direkte fra Visual Studio Code, som beskrevet i Learn om sandbox environments. Det er værdifuldt ved regressionstest, især når der arbejdes med bogføring, lagerlogik, prisberegning eller godkendelsesflow.
Derfra kommer det forretningsnære testforløb, hvor superbrugere validerer rigtige scenarier. Ikke kun den nye funktion, men hele kæden omkring den. En ændring i salgsordrer kan påvirke reservation, levering, fakturering og rapportering længere fremme.
Et brugbart testforløb indeholder typisk disse spor:
- Smoke test efter deployment
- AL-tests for kernefunktioner
- Procesbaseret UAT med superbrugere
- Negativ test af fejlscenarier
Det er fristende at teste direkte mod produktion, især ved små justeringer. Det bør undgås. Der findes mulighed for at åbne en direkte Visual Studio Code-session fra webklienten mod et specifikt production- eller sandbox-miljø til troubleshooting, som beskrevet i Learn om VS Code og web client. Den funktion er nyttig til fejlsøgning, breakpoints og inspektion, men den bør ikke blive en genvej til ændringsudrulning uden et almindeligt releaseflow.
Deployment flow fra sandbox til produktion i Business Central
Selve overgangen til produktion bør følge en fast sekvens. Når udvikling og test er afsluttet, deployes tenant-customization som en .app-fil til produktions-tenant. Det fremgår af Learn om deployment af tenant customization.
Det vigtigste er ikke, om deployment sker manuelt eller via pipeline. Det vigtige er, at den samme proces bruges hver gang, og at den er dokumenteret. Et releaseflow uden variation giver færre overraskelser.
Et sikkert deployment flow kan se sådan ud:
- Kode merges til releasegren efter review.
- Appen bygges med fast versionsnummer.
- Appen deployes til TEST-sandbox.
- AL-tests og UAT gennemføres.
- Release godkendes af både teknik og forretning.
- .app-filen installeres eller opgraderes i produktion.
- Smoke test udføres straks efter go-live.
Hvis løsningen består af flere apps, skal rækkefølgen være fast. Dependencies skal installeres før den app, der bruger dem. Det gælder især ved kombinationer af egne apps, AppSource-apps og per-tenant extensions.
Kopi af produktion til sandbox er en stærk del af dette flow. Når testmiljøet bygger på en frisk kopi, bliver valideringen mere troværdig. Man tester på samme app-version, samme struktur og i mange tilfælde samme datakompleksitet som i live-drift. Det reducerer risikoen for den klassiske situation, hvor “det virkede i test”, men kun fordi testmiljøet var forældet.
Permissions og rettigheder ved ændringer i produktion
Rettigheder er en teknisk detalje, som ofte først får opmærksomhed, når et deployment fejler. Det er for sent.
Deployment til produktion kræver, at man kan logge ind med en bruger, der har adgang til Extension Management. Den rettighed bør ikke ligge bredt i organisationen. Jo færre der kan installere, opgradere eller afinstallere apps i produktion, desto mere stabil bliver driften.
Her giver det mening at skille rollerne tydeligt ad:
- Udvikler: Publicerer DEV-extensions til sandbox og debugger
- Tester/superbruger: Validerer processer og godkender UAT
- Releaseansvarlig: Installerer godkendte apps i produktion
- Driftsansvarlig: Overvåger efter release og håndterer afvigelser
Det samme princip gælder dataadgang. En sandbox, der er kopieret fra produktion, kan indeholde følsomme data. Derfor bør adgangen til testmiljøer styres aktivt. Mange fokuserer på kode og glemmer, at et realistisk testmiljø kræver lige så seriøs governance omkring brugeradgang.
Permissions i selve appen bør gennemgås som en del af testen. Hvis en ny funktion kræver nye permission sets, skal de være på plads før go-live. Ellers får man et “teknisk vellykket” deployment, som brugerne ikke kan arbejde med.
Typiske fejl når sandbox og produktion blandes sammen
De fleste releaseproblemer i Business Central handler om procesbrud, ikke mystiske platformfejl.
Et klassisk eksempel er, at en rettelse publiceres hurtigt til sandbox som DEV-extension, bliver godkendt af forretningen, men aldrig bliver pakket og versioneret korrekt til produktion. Senere står man med forskellig funktionalitet i miljøerne, uden at nogen præcist ved hvorfor.
En anden fejl er at bruge en gammel sandbox til UAT. Hvis produktion har fået nye apps, opsætninger eller dataændringer siden sidst, bliver testresultatet usikkert. Ved større releases bør testmiljøet derfor opdateres ud fra en frisk kopi, så langt forretning og datakrav tillader det.
Typiske faresignaler er:
- Uens versionsnumre uden change log
- Direkte rettelser i sandbox uden commit til Git
- Forretningsgodkendelse uden testcases
- Produktionstilgang til for mange brugere
- Release uden efterfølgende smoke test
Et praktisk minimum setup for mindre og mellemstore virksomheder
Ikke alle har brug for et stort DevOps-setup med mange miljøer og fuld automatisering fra første dag. Det afgørende er at få en model, der er lille nok til at blive brugt konsekvent.
Et godt minimum er én udviklingssandbox, én testsandbox og et produktionsmiljø. Kildekoden ligger i Git. Alle ændringer får versionsnummer. Brugerne tester mod en releasekandidat i TEST. Produktion opdateres kun med den .app-fil, der er godkendt.
Det er ofte nok til at skabe markant bedre kontrol over ændringer i Business Central. Samtidig giver modellen plads til at bygge videre med pipelines, flere testlag og mere automatisering, når behovet vokser.
Når fundamentet er på plads, bliver sandbox ikke bare et sted at “prøve noget af”. Det bliver det miljø, hvor kvalitet skabes, før produktionen mærker ændringen.