UVM.dk Tilstandsrapport for uvm.dk

Transkript

1 UVM Rev: 15 February 2012 Sitecore Sundhedstjek UVM.dk Tilstandsrapport for uvm.dk

2 Indholdsfortegnelse Chapter 1 Introduktion Metode... 3 Chapter 2 Resume... 4 Chapter 3 Løsningsarkitektur Stikprøver fra Sitecore Konfiguration Visual Studio modulering og referencer Visual Studio og Sitecore Templates sammenhæng Stikprøver fra koden Eksempler på kode der kunne blive ryddet op i Campaign Manager Chapter 4 Performance Slutbruger performance Sitecore logfiler Private bytes % Time in GC Udgivelse af indhold Caching Chapter 5 Quality assurance Deployment Vedvarende overvågning af live-miljø Chapter 6 Appendiks UVM Metrics FemtenNulOtte Metrics Fejloversigt for frontend logfiler Page 2 of 18

3 UVM Chapter 1 Introduktion Denne rapport er et resume af sundhedstjek udført på uvm.dk Sitecore-løsningen implementeret af Tjekket er udført i uge 5, Formålet med tjekket er at danne et grundlag for bestemmelse af den overordnede kvalitet af uvm.dk-løsningen og er iværksat på initiativ af Undervisningsministeriet (UVM). Rapporten er målrettet læsere med en dyb teknisk forståelse af Sitecore og relaterede teknologier herunder.net og objektorientret udvikling. Fokus i rapporten er at påpege områder der kan forbedres og dertil komme med forslag til, hvordan disse forbedringer evt. kan udføres, hvor det giver mening. Det er IKKE en del af rapportens fokus at bestemme hvorvidt ændringer vil øge værdien for Undervisningministeriet herunder at bestemme nødvendigheden af at disse forbedringer bliver udført! Det skal dertil også nævnes at ubetinget fokus er på at finde områder der kan forbedres, hvorfor der i mindre grad inddrages de ellers mange positive aspekter af løsningen. Sundhedstjekket er udført af Rasmus Rasmussen, Sitecore i perioden februar 2012, inklusiv en halv dags opstartsmøde med gennemgang af løsningen hos 1508, hvorfra Troels Larsen og Jeppe Andreasen deltog Sundhedstjekket er baseret på tilgængelig backup af kodebase og databaser fra udvikling, samt log- og konfigurationsfiler fra Live Metode Gennemgangen er gennemført ud fra en top-down tilgangsvinkel, hvor løsningen er statisk analyseret for anormaliteter. Dette vil sige stikprøver baseret på erfaring fra tidligere udførte analyser samt konkrete områder tilkendegivet under indledende opstartsmøde fra 1508 s side. Der er derudover kun foretaget yderligere trykprøver på områder, hvor sådanne anormaliteter er fundet. Det skal i denne sammenhæng nævnes, at der indenfor de givne tidsrammer ikke kan gives en endelig garanti for, at alle uhensigtsmæssigheder i hele løsningen er fundet. Konklusioner og anbefalinger er baseret på generel Sitecore best practice såvel som generelt best practice indenfor udviklingsprojekter. Best practice er i denne forbindelse defineret som, hvad der bør gøres med mindre der er en grund til andet. Page 3 of 18

4 Chapter 2 Resume Koncernløsningen til Undervisningsministeriet har en generel høj kvalitet og er opbygget og struktureret efter best practice. Løsningen fremstår således som yderst velfungerende. Løsningen er båret af høj genanvendelse af 1508s eget Sitecore framework, som sikrer en høj kvalitet, da denne kodebase er anvendt på andre løsninger og derigennem er blevet testet over tid. Løsningen fremstår også som en løsning hvor komplekse krav fra UVM har medført komplekse problemstillinger, som til tider har medført komplekse løsninger. Denne kompleksitet ville være noget, som UVM og 1508 i samarbejde kunne nedbringe fremover, efterhånden som løsningen vedligeholdes. Som altid i større udviklingsprojekter er der flere områder i løsningen, som kunne forfines yderligere, så løsningen fremstår endnu mere ren og pænt struktureret. Da der ikke er kritiske fejl i løsningen, fokuserer rapporten på disse områder, hvor der kan foretages yderligere oprydning og afpudsning. Graden af forfinelse skal selvfølgelig altid opvejes ift. økonomi og de evt. gevinster forfinelsen bringer med sig. Dette forholder rapporten sig ikke til. Deployment processer er der godt styr på og 1508s ansvarlige svarer godt for, hvordan en vedvarende høj kvalitet sikres ved opdateringer i Live-løsningen. Processen kunne evt. automatiseres og ensrettes yderligere, hvis der er behov for dette. Page 4 of 18

5 UVM Chapter 3 Løsningsarkitektur Koden består af UVM-specifik kode såvel som et generelt 1508 framework. 3.1 Stikprøver fra Sitecore Generelt fremstår uvm-løsningen meget fleksibel og tilgodeser en del arbejdsgange, som virker elegant løst for redaktørerne. Det meget høje ønske om frihed uden inddragelse af 1508 for redaktørerne giver en del arkitektoniske udfordringer, som virker til at være løst i høj grad. Det anbefales at køre Sitecore s sanity checks på live databasen, som er inkluderet i Sitecore Rocks. Dette vil udmunde i en rapport hvoraf størstedelen vil være mindre issues, som sjældent er show stoppers. Ikke desto mindre kan den tydeliggøre nogle uhensigtsmæssigheder, som bør rettes. Her er en oversigt fra kørslen på udviklingsdatabasen. Det er vigtigt i denne sammenhæng at nævne, at flere af de fundne issues ikke vil optræde i live, da noget af det er testdata. Det er desuden vigtigt at pointere, at de fleste tilfælde betragtes som skønhedsfejl, snarere end problemer. Til sidst dukker der også tilfælde op, som ikke vedrører den del af Sitecore, som kommer fra Et eksempel på et tilfælde er vist her. Page 5 of 18

6 3.2 Konfiguration En stor del af konfigurationen er specificeret i miljøspecifikke delta-filer gennem Visual Studio. Denne fremgangsmåde sikrer korrekte indstillinger ift. forskellige miljøer, men giver ikke mulighed for fragmentering af de enkelte konfigurationsfiler, som potentielt kan vokse sig store over tid. Der er desuden heller ikke fundet deltafiler for modul-specifikke konfigurationsfiler. Nuværende opsætning giver ikke anledning til direkte bekymringer på uvm-løsningen pga. dennes begrænsede størrelse, men på større løsninger ville en højere grad af uniformitet ønskes. 3.3 Visual Studio modulering og referencer UVM kodebasen har både direkte og indirekte cirkulære referencer hvilket medfører øget kompleksitet ift. vedligeholdelse. Dette er visualiseret i nedenstående matrix, hvor blandingen af grønne og blå markeringer på begge sider af skillelinjen indikerer cirkulære referencer på tværs af lag. Sorte markeringer indikerer direkte cirkulære referencer mellem de angivne namespaces. Page 6 of 18

7 UVM Samme tendens går igen i 1508 framework delen Page 7 of 18

8 3.4 Visual Studio og Sitecore Templates sammenhæng Der er ikke stor sammenhæng mellem kodebase og Sitecore templates. Dertil er arkitekturen centreret omkring funktionalitet og typer. Dette er medvirkende til en lavere grad af overblik i løsningen, hvilket besværliggør vedligeholdelse. 3.5 Stikprøver fra koden UVM-koden består af linjer kode fordelt på 512 typer frameworket består af linjer kode fordelt på 232 typer. Generelt fremstår 1508 kodebasen som kode der er udviklet og testet over tid, hvilket medfører en høj grad af sikkerhed for, at koden virker. Den udstråler dog også i høj grad at være en kode base hvor der bliver tilføjet og rettet, men i mindre grad slettet. Page 8 of 18

9 UVM Eksempelvis slutter FemtenNulOtte.SitecoreServices.SitecoreService på linje 1186 og arver fra CmsService, der slutter på linje 592. Især førstnævnte klasse indeholder en del kode, som enten ikke bliver brugt eller som er udkommenteret. Det vidner om en kodebase, hvor der mangler overblik, så man tør ikke slette noget af frygt for det skal bruges et andet sted. Det vidner desuden om en monolitisk arkitektur, som med tiden bliver sværere og tungere at vedligeholde Eksempler på kode der kunne blive ryddet op i Disse eksempler er fundet i FemtenNulOtte.SitecoreServices.SitecoreService, som er en del af den generelle kodebase Hardcodet databaser og ubrugt kode I denne kode er databaser hardcodet hvilket umuliggør indførsel af yderligere publishing targets. Samme funktion har linjen efter ubrugt kode, som bør slettes. Næste eksempel er anvendelsen af debug sympoler. Dette vidner om en ustruktureret testmetode, hvor det er den givne udvikler der skal vide, hvornår denne hændelse forventes at ske. Det anbefales at teste sådanne scenarier i mere strukturerede integrations tests. Dette kan potentielt nedsætte performance Bruge af descendants-aksen frarådes, da denne potentielt kan lægge et helt site ned, hvis der forespørges på en akse, der indeholde mange items. Brugen af descendants aksen er fundet flere steder i både den umv-specifikke kode og 1508s generelle framework. Det skal i den sammenhæng kraftig påpeges, at koden i sig selv ikke giver problemer og sagtens kan bruges de rigtige steder. I forbindelse med performance problemer vil dette dog være et af det første steder man starter med at undersøge nærmere. Page 9 of 18

10 SecurityDisabler Det anbefales at bruge Sitecore.Security.Accounts.UserSwitcher i stedet for SecurityDisabler hvor det er muligt, for bedre audit log. En hurtigt søgning giver 37 hits fordelt på både den UMV-specifikke kode, samt det generelle framework Campaign Manager Uvm.dk anvender Sitecore s ECM til udsendelse af nyhedsbreve. Et centralt begreb i den sammenhæng er udsendelsen af nyhedsbreve til abonnenter baseret på disses præferencer herunder hvilke interesseområder de er tilmeldt. En bruger der abonnerer på områder, der ikke er nogen nyheder under, skal ikke modtage et nyhedsbrev. Det anbefales at udføre denne udvælgelse i DispatchNewsletter pipelinen i stedet for Send for bedre integration med Sitecore Analytics og mindre overhead da SendMail pipelinen aldrig vil blive startet, når udvælgelsen sker i DispatchNewsletter Dette er et område, som 1508 allerede er bekendt med. Page 10 of 18

11 UVM Chapter 4 Performance Dette afsnit indeholder analyse og anbefalinger ift. performanceoptimering. Det skal i denne sammenhæng påpeges at performanceoptimering, som udgangspunkt, kun anbefales ved en løsning der ikke kører tilfredsstillende. Det skal desuden siges, at optimering af performance, som udgangspunkt, altid går ud over vedligeholdelsesvenlighed og at det i praksis altid er muligt at optimere yderligere. Med andre ord er alle fremlagte data i dette afsnit noget som skal holdes op imod den overordnede samlede brugeroplevelse, som i sidste ende er det vigtigste i denne sammenhæng. Målinger er foretaget på en af CD serverne. 4.1 Slutbruger performance Stikprøvekontrol på forsiden af uvm.dk viser overvejende god opfyldning af anbefalinger fra YSlow, som er Yahoo s svar på best practice ift. opbygning af html og brug af ressourcer. Page 11 of 18

12 4.2 Sitecore logfiler Sitecores logfiler er første skridt ift. sikring af høj driftsikkerhed, men kan ikke stå alene i en vurdering af løsningskvalitet. Logfiler for én af frontend serverne er scannet for uregelmæssigheder. Logfilerne dækker perioden I den uge inkl. én weekend er der genereret logfiler for 20mb. Dette er ikke alarmerende meget, men indikerer en løsning der ikke er gået efter i sømmene i drift, da logfilerne viser af fejl der ikke er håndteret. Page 12 of 18

13 UVM Grunden til, at små logfiler er ønskværdige er fordi ellers show stoppers risikerer at drukne i støjen. Her er fejl vist, som optræder mere end 100 gange i perioden. Især de to første skaber en del støj og stammer formodentlig fra samme stykke kode. 4.3 Private bytes En lineær trend viser, at hukommelsesallokeringen ligger jævnt omkring 700mb, med enkelte udsving på helt op til 1,6 gb. Dette giver ikke umiddelbart grund til nogen bekymring med mindre de her udsving sammenfalder med mærkbar performancedegradering på løsningen. Bytes in all heaps ligger og svinger jævnt omkring 250 mb Page 13 of 18

14 4.4 % Time in GC Profilering af %Time in GC indikerer intens garbage collecting hvilket tyder på overdrevet instansiering af objekter, som smides væk umiddelbart efter. Dette er i sig selv ikke et problem, hvis løsningen kører fint, men et sted der tyder på store muligheder for performanceoptimering. Datagrundlaget er dog ikke fyldestgørende nok til at identificere årsagen til disse udsving i GC. 4.5 Udgivelse af indhold 1508 nævner, at der ikke foreligger nogen publiceringsstrategi, men at redaktører publicerer efter forgodtbefindende. Hver publicering dræber en del af cachen og der ligger en stor potentiel performance forbedring at hente her. 4.6 Caching 1508 frameworket indeholder egen cache-mekanisme. Det er ikke afdækket i hvor høj grad denne er brugt på uvm løsningen. Bagsiden af medaljen ved brug af egen cache er, at Sitecores indbyggede Page 14 of 18

15 UVM profileringsværktøjer ikke virker og det dermed kan være sværere at debugge og performance-optimere kørende løsninger. Page 15 of 18

16 Chapter 5 Quality assurance 5.1 Deployment 1508 anvender Visual Studios deployment pakker, hvilket sikrer en høj sikkerhed i garantien for fuldstændighed deployment af opdateringer anvender ikke automatisk inkludering af items fra Sitecore i generering af opdateringspakker. Det anbefales, at de undersøger hvorvidt TDS kan afhjælpe dette. Der er dog ikke meldt tilbage om problemer og behov for regressionstests ifm. opdateringer og udrulninger, hvilket ikke giver anledning til yderligere anbefalinger på dette område. 5.2 Vedvarende overvågning af live-miljø Der blev ikke oplyst om nogen proaktiv overvågning af Sitecore logs i livemiljø fra hverken UVM eller 1508 s side. Det anbefales at Undervisningsministeriet tager initiativ til at afsætte midler til at der jævnligt overvåges logs i live miljøet og at antallet af fejlmeddelelser mm. nedbringes betragteligt, da det er med til at sikre en mere stabil drift. Page 16 of 18

17 UVM Chapter 6 Appendiks 6.1 UVM Metrics # Lines of code : 7,816 # Assemblies : 4 # Namespaces : 94 # Types : 514 # Methods : 3,365 # Fields : 1,078 # IL instruction : 60,631 # Lines of comment : # Classes : 497 # Abstract classes : 9 # Interfaces : 4 # Value types : 0 # Exception types : 1 Third Party Usage # Attribute types : 0 # Delegate types : 11 # Enumeration types : 13 # Generic methods : 10 # Generic types : 11 # Assemblies used : 21 # Namespaces used : 120 # Types used : 542 # Methods used : 1,210 # Fields used : FemtenNulOtte Metrics # Lines of code : 5,425 # Assemblies : 5 # Namespaces : 47 # Types : 232 # Methods : 1,734 # Fields : 490 # IL instruction : 39,955 # Lines of comment : # Classes : 221 # Abstract classes : 8 # Interfaces : 1 # Value types : 0 # Exception types : 0 Third Party Usage # Attribute types : 1 # Delegate types : 2 # Enumeration types : 10 # Generic methods : 109 # Generic types : 10 # Assemblies used : 12 # Namespaces used : 88 # Types used : 436 # Methods used : 993 # Fields used : Fejloversigt for frontend logfiler Page 17 of 18

18 Page 18 of 18