Stora förändringar kräver stora förändringar

Spintr börjar närma sig slutet på en övergång från .NET Framework 4.x till Microsofts nya plattform för mjukvaru-utveckling. Ett massivt arbete som medfört att vi lärt oss en hel del saker som kan vara värda att känna till.

Redan under 2014 började Microsoft prata om en ny version av .NET som skulle vara snabbare, bättre, plattformsoberoende och byggt med öppen källkod. Versionen kallades vNext då de ännu inte bestämt sig för hur de ville ha versionerna. I juni 2016 kom den första versionen av det nya ramverket och .NET Foundation har sedan dess fortsatt att utveckla .NET Core.

Kring årsskiftet bestämde vi oss för att projektet mognat tillräckligt för att vi skulle våga ta steget över till det nya ramverket. Vi började med att köra ett av Microsoft förberett verktyg som analyserade vår kod och gav oss en ungefärlig bild av hur mycket jobb vi hade framför oss. Vi har sedan dess arbetat med övergången parallellt med vidareutvecklingen av vår integration med Office 365. Nedan beskriver vi några av de upptäckter vi gjort under vår resa som kan vara värt att känna till – både för utvecklare och andra yrkesgrupper inom IT-sektorn.

.NET Core är plattformsoberoende

Som vi nämnde tidigare är .NET Core plattformsoberoende och kan byggas, testas och driftsättas i en macOS eller Linuxmiljö lika lätt som du sätter upp det på en Windows-server. För .NET Foundation innebar detta att man var tvungen skriva om mycket från början, men detta innebar även att man kunde göra sig av med gammal kod vars enda uppgift var att stödja teknik som i vissa fall var över 15 år gammal.

Ny webbserver

I och med att man gjorde .NET Core plattformsoberoende behövde man se till att webbapplikationer kunde driftsättas utan krav på att servern körde Microsofts IIS. En webbserver som är plattformsoberoende utvecklades, som inte behöver vara bakåtkompatibel med flera år gammal teknologi och som kunde optimeras från grunden för den typen av arbete som ASP.NET-projekt utför. Kestrel, som den nya webbservern fick heta, är enligt Microsoft, upp till 20 gånger snabbare än IIS.

Skönare för utvecklare

Med .NET core har stora delar gjorts om så att de numera är mer utvecklarvänliga.  Vissa bitar, som till exempel beroendeinjicering och hur man konfigurerar loggning och inställningar, har arbetats om för att vara smidigare. Man har dessutom sett till att göra det lättare för utvecklare att skriva sina egna implementationer av stora delar av ekosystemet.

Stora förändringar kräver stora förändringar

Alla de förändringar som gjorts kan göra att delar av ens befintliga kod inte längre går att köra – något som vi på Spintr har fått uppleva och hantera. Namnrymden System.Drawing som hanterade kod-interaktioner med bilder har försvunnits och ett frivilligprojekt har sprungit upp för att ta dess plats och vissa IO-hjälmedel (Input/Output) har bytt namn, plats och beteende. 

Extrapaket som Json.NET har ändrat beteende till att tvinga så kallad “camelCasing” som standard. Det populära ORM-verktyget EntityFramework har i sin .NET Core-version gjort om hur databasfrågor genereras vilket kan göra att man behöver se över vissa av de databasfrågor man gjort via EntityFramework.

Det gamla systemet med HttpModules och HttpHandlers har gjorts om och bytts ut mot ett nytt “middleware”-system likt det man kan hitta i andra webbramverk. De är lättare att arbeta med, men introducerar nya utmaningar då ordningen i vilket de körs spelar stor roll. Om man, till exempel, vill ta in en ApplicationInsights-middleware bör man se till att det är den första middleware:n som körs, annars kan man tappa värdefull information.

Vidareutvecklas ständigt

.NET Foundation och Microsoft arbetar hela tiden med att göra .NET Core snabbare, bättre och trevligare för utvecklare och det märks. För den som följer .NET Core och dess kringliggande projekt finns det alltid något nytt att läsa – från nya benchmarks som visar på prestandavinningar till nya verktyg som hjälper oss utvecklare att bygga bättre applikationer åt våra användare. 

Eftersom att man valt att göra projektet OpenSource kan vem som helst skicka in buggar, förbättringsförslag eller andra synpunkter. Därmed kan .NET röra sig snabbare framåt än vad man kunnat tidigare.

Lärdomar att dra

Utifrån resan vi gjort med .NET Core under den senaste tiden kan jag se att dessa saker är de som du bör ha i åtanke om du står inför en liknande resa:

• Kör ett analysverktyg på er kod innan och välj ut hur ni skall ersätta de beroenden som inte längre finns tillgängliga – det sparar tid i längden.
  
  
• Ta tillfället i akt att byta ut gamla saker och kanske till och med dra nytta av det som är nytt i .NET Core (e.g. loggning och beroendeinjicering). 
  
  
• Att projektet bygger och alla tester körs utan problem betyder inte att allt kommer att fungera i produktion. Engagera ert QA-team och testa allt grundligt.

.NET Core och Spintr

Spintr sitter som tidigare nämnt i slutfasen på vårt projekt att flytta över vår kodbas till .NET Core och har i våra interna tester sett stora prestandaförbättringar. Det är självklart lite läskigt i och med att vi praktiskt taget bytt ut hela skelettet i produkten, men vi sitter just nu med ett rigoröst testarbete för att se till att förändringen inte påverkar beteendet i produkten. Vår målsättning just nu är att kunna skeppa ut förändringarna under april månad till våra kunder i molnet och förhoppningsvis kommer de då att kunna uppleva ett ännu snabbare och pålitligare Spintr.