Vi har ikke tid og ressurser til å gjøre en oppgradering nå

Vi har ikke satt av penger til å gjøre en oppgradering nå

Det er for stor risiko til at ting slutter å virke etter oppgradering

Dette er ofte årsaker til beslutninger om å ikke oppgradere kjernesystemer i en bedrift. Ihvertfall før inntoget av SaaS løsninger.

En av de største utfordringene til tradisjonelle on-premises (lokalt installert) programvare er at det er tidkrevende og kostbart å oppgradere, både mindre bug-fix versjoner (minor versions) og hovedversjoner (major versions). Mange on-premises systemer krever også oppgradering av hver klient-maskin etter oppgradering av serverside. Dersom man i tillegg har utviklet diverse tilpasninger og integrasjoner i applikasjonene krever det som oftest mye arbeide i å sette opp et testmiljø, oppgradere testmiljøet og utføre testing av integrasjoner, workflows og andre tilpasninger. Det er heller ikke uvanlig at man også må gjøre programmatiske endringer og rekompilere opp mot ny interop’er, proprietære biblioteker og dll’er tilhørende programvaren. Har man i også gjort endringer i kjernen av systemet, triggere på SQL nivå, endringer i ressursfiler i applikasjon og på toppen av det hele har dårlig dokumentasjon på hva som er gjort hvor så har man satt seg i en «umulig» situasjon i forhold til oppgradering. Jeg har til og med hørt om situasjoner hvor kunder har valgt å ikke oppgradere noen sinne pga det rett og slett føles ut som en uoverkommelig oppgave og for høy risiko. Resultatet er at virksomheter ofte henger igjen på gamle versjoner av programvaren og får ikke være med på verken utbedringer, forbedringer og ny funksjonalitet i applikasjonen, noe som til slutt medfører til ineffektivitet og lite fornøyde brukere.

Heldigvis er dette radikalt endret med innføring av SaaS

Heldigvis er dette radikalt endret med innføring av SaaS (Software as a Service) pga tilbyderne av forretningsapplikasjoner som regel har en felles infrastruktur delt over flere brukere og på den måten er det enklere å ha alle brukere på nyeste og samme versjoner. Microsoft Dynamics 365 er en forretnings applikasjon svært mye standard funksjonalitet, men som også er svært godt tilrettelagt for utvidelse av funksjonalitet både ved bruk av OOB (Out of the box) konfigurasjonsverktøy og utvikler API. For å unngå å havne i samme «felle» som on-premis miljøer har Microsoft derfor lagt til rette en rekke verktøy og strategier for å lette prosessen med oppgradering. De viktigste elementene er:

  • Continuous deployment betyr at programvaren blir kontinuerlig oppgradert, gjerne flere ganger i måneden med rettelser og utbedringer på eksisterende funksjonalitet. Dette gjør at man slipper å vente lenge på ny hovedversjon før rettelser og forbedringer blir rullet ut. Tidligere ble dette gjerne gjort i større «service-packs» som igjen krevde en egen prosess for testing før oppgradering. Med mindre continuous deployment er det lite behov for en slik test prosedyre da hver oppdatering er så liten, godt kontrollert og testet av Microsoft at dette bare går av seg selv uten at brukerne merker noe til det.
  • Customer Driven Updates betyr at Dyanmics 365 administrator selv bestemmer hvilke dato/tidspunkt oppgradering til nye hovedversjoner skal skje via admin grensesnittet til Dynamics 365. Selve oppgraderingen utføres av i en automatisert prosess fra Microsoft side og utføres uten ekstra kostnad i seg selv. Før oppgraderingen starter kjøres det noen automatiske rutiner for å kontrollere kompatibilitet og for potensielle problemer, samme gjøres etter oppgradering er utført. Dersom det skulle oppstå et problem blir oppgraderingen automatisk rulle tilbake til original tilstand før oppgraderingen startet.

  • Microsoft har lagt til rette for at man med «one-click» kan kopiere hele produksjonsdatabasen med all alle data og konfigurasjon til et separat testmiljø (Sandkasse), som man via customer driven update kan oppgradere først for å teste integrasjoner, workflows og evt. andre tilpasninger. Her kan man også teste ut forbedringer i eksisterende funksjonalitet og nye funksjoner, lage brukerveiledninger og forberede hvordan organisasjonen kan ta i bruk ny og forbedret funksjonalitet. Min erfaring er at det er krevende å ha et oppdatert testmiljø, både med oppdaterte data og konfigurasjoner og dermed blir det vanskelig å gjennomføre ordentlig testing for oppgradering av produksjonsmiljøet. Et lite tankekors og noe man må ta hensyn til er GDPR håndtering. Dersom man får en DSR (Data Subject Request), spesielt i form av sletting, så må man også slette i testbaser.
  • Microsoft har en strategi med Dynamics 365 at all type endret eller ny funksjonalitet som potensielt kan medføre store endringer for brukerne standard er slått av og må aktiveres av Dynamics 365 administrator om det skal tas i bruk. På den måten kan oppgraderinger utføres i 2 faser slik at en oppgradering ikke nødvendigvis oppleves som noen stor endring fra brukerens side og som vil kreve ny brukeropplæring med tilhørende support. Dermed kan man planlegge at man i «fase 2» av en oppgradering tar i bruk endret og ny funksjonalitet i sitt eget tempo.
  • Dynamics 365 lanseres med 2 nye hovedversjoner i året, en i april og en i oktober. Release notes til disse slippes gjerne flere måneder i forveien, f.eks. ble release notes til oktober 2018 (release 9.1) offentliggjort i midten av juli. I tillegg til dette har Microsoft et helt åpent og transparent roadmap slik at man også kan holde seg oppdatert på hva man muligens kan forvente i neste versjon. På den måten har man mulighet til å sette seg inn i- og forberede oppgraderinger i god tid.
  • Microsoft har en uttalt strategi at så lenge man benytter seg av dokumenterte og supporterte metoder i integrasjoner, workflows og andre tilpasninger vil disse i størst mulig grad og så langt det lar seg gjøre være upåvirket etter oppdatering til en ny hovedversjon. Dette for å gi virksomheter en god forutsigbarhet og langsiktighet i sin implementering. Noen ganger må Microsoft imidlertid fjerne støtte for enkelte ting for å kunne videreutvikle og forbedre applikasjonen generelt sett. Da dokumenteres dette i god tid, gjerne 1-2 år i forkant at en funksjon vil bli «depricated». Når en funksjon har status depricated betyr nødvendigvis ikke det at den blir borte eller slutter å fungere, men da kan Microsoft velge å fjerne funksjonen ved en framtidig versjon og de er ikke forpliktet til å supportere eller fikse et. evt. problem som oppstår i en depricated funksjon. Som en systemarkitekt og DevOps bør man derfor alltid ha oversikt over depricated funksjoner slik at man ikke baserer funksjonalitet på bruk av en varslet eller allerede depricated funksjon.
  • Dynamics 365 består av et «eco-system» med en rekke andre forretnings applikasjoner og tilhørende tjenester som Microsoft selv sørger for å teste og holde kompatibelt med nyeste versjoner. Bruk av disse andre tjenestene kan man trygt forvente også skal fungere etter nye oppgraderinger om ikke annet er dokumentert i release notes. Eksempler på det er integrasjoner mot Exchange EWS, Outlook klient, Sharepoint, Microsoft Logic Apps, Microsoft Flow, Microsoft PowerApp og PowerBI. Man bør imidlertid være bevist på å kontrollere at 3-parts moduler og connectorer til Logic Apps og Flow er kompatibelt med versjonen av Dynamics man oppgraderer til. Dette kan man som nevnt tidligere i artikkelen kontrollere i sandbox/testmiljøet.

Spesielt for kunder som oppgraderer fra versjon 8.2 til 9.0 eller 9.1 må man passe på at man må ta i bruk ny krypteringsprotokoll basert på TLS 1.2 for applikasjoner som logger seg på Dynamics 365 via web api’et. Eksempler på det kan være Logic Apps, Flow og Azure Functions som henter eller skriver data til Dynamics. Vår anbefalning er å endre til .net rammeverk versjon 4.6.2 eller høyre og deretter rekomplilere for å få automatisk støtte for TLS 1.2 protokoll. Ofte er det ikke behov for noen rekompilering i det hele tatt om man har kun benyttet seg av supporterte og dokumenterte metoder. For å sette det i perspektiv ble TLS 1.2 lansert i 2008 og først nå i oktober 2018 ble versjon TLS 1.3 lansert. Min antakelse er at TLS1.2 og TLS1.3 vil kunne brukes side om side i lang tid før man «må» gå over til å bruke nyere versjon, slik man nå er tvunget til å gå fra TLS1.1 til TLS1.2.

Andre aspekter å tenke på, som ikke er spesielt til denne versjonen, er at når man går fra et hovedgren til en annen, dvs fra 8.2. til 9.0, kan man ikke eksporter en managed solution fra utviklingsmiljø basert på 9.0/9.1 til 8.2 versjon. Derimot kan man eksportere en managed solution fra 9.1. til 9.0. Man må derfor planlegge nøye når utviklings instansen oppgraderes i forhold til at det ikke bør gå for lang tid mellom utviklingsinstansen og produkjonsinstans er oppgradert. Et alternativ er å opprette ny utviklingsinstans basert på samme versjon som man skal oppgradere til og i en periode har 2 utviklingsinstanser hvor man eksporterer ut en unmanaged solution fra 8.2 versjon til en 9.0/9.1 sandbox etter endringer er utført i 8.2.

Avant IT er «født» i skyen og Norges første Gold Cloud Microsoft CRM Partner. Denne partnerstatusen har bl.a. krav til antall kunder Online/SaaS versjon og antall sertifiserte konsulenter og utviklere. Vi har derfor mye erfaring med disse oppgraderingsprosessene. Vi vil i løpet av 2018 ha oppgradert alle våre kunder til siste versjon 9.1 av Dynamics 365.

Lykke til!

Forfatter: Stig Karlsen / https://www.linkedin.com/in/karlsenstig/