D365 Opdateringer: Hvor Ofte & Hvordan?

Da Microsoft Dynamics 365 for Finance and Operations blev lanceret, var en af de mest markante ændringer overgangen til en model, hvor kode og objekter skal udvides i stedet for at blive overskrevet direkte. Denne arkitektoniske ændring har medført enorme fordele, især i forbindelse med systemopdateringer. D365's kontinuerlige opdateringer gør det muligt at anvende nye hotfixes og funktioner uden at gribe ind i eller overskrive den specialudviklede kode. Resultatet er en massiv besparelse i tid og penge, da kode ikke længere skal flettes manuelt, hver gang en ny version frigives. Alligevel er der vigtige aspekter at forstå omkring, hvordan disse nye versioner anvendes i de forskellige miljøer for at sikre en stabil og forudsigelig drift.

Fire Nye Versioner Hvert År

En central del af D365's livscyklus er, at Microsoft frigiver en ny version af platformen fire gange om året. Disse opdateringer kaldes ofte "D365 continuous updates" eller "service updates". De følger en forudsigelig tidsplan, hvilket giver virksomheder mulighed for at planlægge deres interne test- og implementeringsprocesser. Typisk frigives disse opdateringer i marts, juni, september og december. Selvom datoerne kan variere en smule, stræber Microsoft efter at overholde denne kadence for at skabe forudsigelighed for administratorer og udviklere.

Hver version bygger videre på den forrige og introducerer nye funktioner, forbedringer af ydeevnen og vigtige sikkerhedsrettelser. Versionsnummereringen følger et klart mønster, f.eks. '10.0.41', hvor det sidste tal øges for hver ny udgivelse. Denne struktur gør det nemt at identificere, hvilken version et system kører, og planlægge opgraderinger til nyere versioner.

Kun To Årlige Opdateringer er Obligatoriske

Selvom der frigives fire opdateringer om året, kræver Microsoft kun, at administratorer anvender to af dem. Dette giver en betydelig fleksibilitet. Specifikt kan en administrator vælge at sætte én opdatering på pause (dvs. springe den over), men den efterfølgende opdatering skal så installeres. Det er ikke muligt at springe to opdateringer over i træk. Denne politik sikrer, at ingen systemer kommer for langt bagefter den nyeste version, hvilket er kritisk for support og sikkerhed.

Hvorfor vælger mange kun at tage to opdateringer? Svaret er ressourcer. Hver opdatering bør gennemgå en grundig testproces for at sikre, at alle systemets tilpasninger og integrationer fungerer korrekt med Microsofts nye kode. Test er ofte en manuel og tidskrævende proces. Ved at reducere antallet af årlige opdateringer fra fire til to kan virksomheder halvere den tid, der bruges på regressionstest, og dermed frigøre ressourcer til andre værdiskabende opgaver. De mest almindelige strategier er at opdatere i marts og september eller i juni og december.

Forståelse af Automatiske Opdateringer

Som standard vil Microsoft automatisk anvende hver nye version til produktions- (PROD) og testmiljøer (STAGE) i henhold til en fastlagt tidsplan i Life Cycle Services (LCS). Mange administratorer lader disse automatiske opdateringer køre som planlagt, især i systemer med få eller ingen tilpasninger.

Selvom D365's arkitektur forhindrer Microsofts opdateringer i direkte at overskrive brugerdefineret kode, er der stadig en risiko. Udviklere kan tilføje kode, der kører, når Microsofts standardkode eksekveres. Dette er en almindelig metode til at tilføje ekstra validering eller funktionalitet til en eksisterende proces. Hvis Microsoft ændrer sin standardkode, kan den brugerdefinerede kode dog opføre sig anderledes eller helt fejle. Selvom det ikke sker ofte, kan der opstå problemer, som kræver, at den brugerdefinerede kode justeres. Derfor er det stærkt anbefalet, at alle D365-miljøer med brugerdefineret kode først tester den nye version i et dedikeret TEST-miljø, før opdateringen rulles ud i produktion.

Opgraderingsprocessen: En Trin-for-Trin Guide

For virksomheder med tilpasset kode er en struktureret opgraderingsproces afgørende for at minimere risici. Følgende trin anbefales for en sikker og kontrolleret udrulning af en ny D365 service update.

1. Download og Anvend Pakken i et Testmiljø

Det første skridt er at downloade den relevante service update-pakke fra asset library i Life Cycle Services (LCS). Denne pakke anvendes derefter på dit primære TEST-miljø. Dette miljø bør være en nylig kopi af dit produktionsmiljø for at sikre, at testresultaterne er så retvisende som muligt.

2. Grundig Test i TEST-miljøet

Dette er den mest kritiske og tidskrævende fase. Her skal alle forretningskritiske processer testes grundigt. Microsoft har allerede testet standardfunktionaliteten, så fokus bør ligge på områder med tilpasninger, integrationer til tredjepartssystemer og kritiske forretningsprocesser. Eksempler på processer, der altid bør testes, inkluderer:

• Oprettelse og fakturering af salgsordrer
• Gennemførelse af indkøbsprocessen
• Lagerstyring og produktion
• Finansielle månedslukningsprocedurer

Brug af automatiserede testværktøjer kan fremskynde denne proces betydeligt, men manuelle tests af nøglefunktioner er stadig uundværlige.

3. Implementering i STAGE-miljøet

Når alle tests er bestået i TEST-miljøet, skal den præcis samme pakke anvendes på STAGE-miljøet (også kendt som pre-production eller UAT-miljø). Det er afgørende, at det er den identiske pakke. Hvis du downloader en ny pakke fra LCS, selvom den har samme versionsnummer, kan den indeholde yderligere hotfixes, som ikke var med i den version, du testede. At introducere utestet kode på dette stadie er risikabelt. STAGE-miljøet bruges til en sidste validering, ofte af superbrugere, før den endelige udrulning til produktion.

4. Udrulning til Produktion

Efter vellykket validering i STAGE markeres pakken som en "release candidate" i LCS. Herefter kan den planlægges og anvendes på produktionsmiljøet. Det anbefales at udføre denne opdatering uden for normal arbejdstid for at minimere forstyrrelser. Efter opdateringen er det god praksis at verificere, at de mest kritiske forretningsprocesser fungerer som forventet. Hvis der opstår alvorlige problemer, har LCS funktioner til at rulle opdateringen tilbage.

5. Pause af Fremtidige Automatiske Opdateringer

Når du manuelt har opdateret dit produktionsmiljø, er det vigtigt at gå ind i LCS og aktivt sætte de kommende automatiske opdateringer på pause. Gør du ikke dette, vil LCS på et senere tidspunkt forsøge at anvende en automatisk opdateringspakke, som igen kan indeholde kode, du ikke har testet. Pausen sikrer, at du bevarer fuld kontrol over, hvornår og hvilken version der kører i dit produktionsmiljø.

6. Opdatering af Alle Resterende Miljøer

Det sidste trin er at sikre, at alle andre miljøer, herunder udviklingsmiljøer (Dev) og eventuelle build-miljøer, opdateres til den samme version som produktion. Dette er vigtigt af to grunde:

1. Fejlfinding: For at kunne genskabe og fejlfinde et problem fra produktion i et udviklingsmiljø, skal kodegrundlaget være identisk.
2. Databasegendannelse: Det er almindelig praksis at gendanne en backup af produktionsdatabasen i et udviklings- eller testmiljø. Denne proces vil sandsynligvis fejle, hvis miljøet ikke kører den samme platformversion som databasen.

Find Opdateringsdatoen i Life Cycle Services (LCS)

Den mest præcise måde at finde datoen for den næste automatiske opdatering er direkte i LCS. Følg disse trin:

1. Log ind på lcs.dynamics.com og vælg dit projekt.
2. Klik på menuikonet (tre linjer) og vælg 'Project settings'.
3. Gå til fanen 'Update settings'.
4. Her finder du links som 'View the update calendar' og 'Pause upcoming update'. Begge viser en kalender med de planlagte datoer.

Kalenderen vil tydeligt vise, hvornår dit 'Acceptance Testing environment' og dit 'Production environment' er planlagt til automatisk opdatering. Datoen for produktionsmiljøet er din endelige deadline for at have gennemført din manuelle opdateringsproces og sat de automatiske opdateringer på pause.

Ofte Stillede Spørgsmål (FAQ)

Hvor mange D365-opdateringer udgives årligt?

Microsoft udgiver fire service updates om året, typisk i marts, juni, september og december.

Skal jeg installere alle fire opdateringer?

Nej, det er kun obligatorisk at installere to opdateringer om året. Du kan springe én opdatering over, men ikke to i træk. Dette giver fleksibilitet til at planlægge testressourcer.

Hvad er den største risiko ved automatiske opdateringer?

Den største risiko er, at ændringer i Microsofts standardkode kan forårsage uventet adfærd eller fejl i dine tilpasninger og integrationer. Derfor er grundig test i et separat miljø afgørende, før en opdatering rammer produktion.

Hvorfor er det vigtigt at bruge den samme pakke i TEST, STAGE og Produktion?

For at sikre, at det, du tester, er præcis det samme som det, du udruller. En ny downloadet pakke, selv med samme versionsnummer, kan indeholde nye hotfixes, som ikke er blevet testet, hvilket introducerer en unødvendig risiko.

Hvad sker der, hvis jeg ikke pauser den automatiske opdatering efter en manuel opdatering?

Hvis du ikke pauser den, vil LCS på den planlagte dato forsøge at installere en ny opdateringspakke oven på din nyligt opdaterede version. Denne nye pakke indeholder kode, du ikke har testet, hvilket underminerer hele din kontrollerede udrulningsproces.

Konklusion

Microsoft har skabt en robust arkitektur, hvor nye versioner kan anvendes som kontinuerlige opdateringer uden at overskrive brugerdefineret kode. Dette sparer en enorm mængde tid sammenlignet med tidligere ERP-systemer, hvor kodemanagement var en stor byrde. Dog er der stadig en risiko for, at eksisterende tilpasninger ikke fungerer som forventet med den nye version. Derfor er en disciplineret testproces essentiel. Ved at forstå tidsplanen, udnytte fleksibiliteten i kun at tage to årlige opdateringer og følge en struktureret udrulningsproces kan virksomheder holde deres D365-platform opdateret, sikker og stabil med minimal risiko.