Blogg | Artikel

Boards on Fires resa till Microsoft Azure

Mycket har hänt i produktutvecklingen på Boards on Fires resa från idé till första lansering och vidare mot ett system för digital daglig styrning i världsklass. I den här artikeln berättar vår utvecklare Tobias Runesson om insatserna som krävts för att skala upp och teamet som gjort det möjligt!

Boards on Fire tar form  

År 2018 påbörjade utvecklarna Ola Karlsson och Gabriel Svennerberg, i skuggan av sina konsultuppdrag, ett projekt som skulle hjälpa Växjö Kommuns IT-avdelning arbeta effektivare med daglig styrning. Den ursprungliga idén var enkel: digitalisera whiteboards och skapa en produkt som främjar effektivitet, dataflöden och engagemang. Snabbt togs en MVP (Minimum Viable Product) fram, och 2019 inleddes nästa steg när Beds by Scapa hoppade ombord för att bygga vidare på idén.  

Sedan dess har produktutvecklingen gått snabbt och systemet har växt fram till att bli ett ledande system inom digital daglig styrning. I slutet av 2020 insåg vi på Boards on Fire att potentialen var enorm. Med flera nöjda kunder och en stadigt växande efterfrågan var beslutet enkelt: det var dags att bygga ett system i världsklass. Ett system som skulle vara modernt, stabilt, robust, säkert och skalbart. Detta skulle kräva en övergång från Ruby on Rails till .NET och en flytt från Heroku till Microsoft Azure. En rejäl ombyggnad av systemarkitekturen låg framför oss, men det var ett beslut som skulle lägga grunden för framtidens Boards on Fire.   

En växande produkt med stora ambitioner  

Med den nya visionen följde även flera utmaningar. Att gå från Ruby, ett dynamiskt språk, till .NET:s starkt typade värld innebar en stor förändring. Vi behövde inte bara hantera äldre data på nya sätt, utan också anpassa och optimera hur information sparas och uppdateras. Det som gör Boards on Fire unikt är dess flexibilitet, där varje kund kan skapa sina egna datamodeller – vilket ställer höga krav på datastrukturer. Detta krävde att vi tänkte nytt och omprövade tidigare lösningar för att skapa ett system som är lika flexibelt som säkert.  

Vi visste också att vi hade en teknisk skuld från produktens tidiga stadie som POC (Proof of Concept). Detta behövde åtgärdas för att bygga en hållbar lösning. En annan avgörande utmaning var att migrera alla befintliga kunder till den nya plattformen, utan att på något sätt störa deras dagliga användning.   

Till detta kom ytterligare faktorer: ett nytt utvecklingsteam som skulle formas, processer som skulle sättas, och begränsad produktkunskap hos flertalet utvecklare. Bara tre av sex hade erfarenhet av Ruby on Rails, vilket innebar en viss inlärningskurva. Och medan vi arbetade med migreringen fortsatte den befintliga produkten att användas av kunder, vilket krävde löpande ändringar och support i den också.  

En ny utvecklingsprocess växer fram  

Vi startade med att bygga teamet – Martin Kassar, Jonas Sjöberg, Tobias Runesson, Ola Karlsson, Gabriel Svennerberg och Johan Hultgren – och etablera en tydlig och effektiv utvecklingsprocess. Eftersom vi alla hade gedigen erfarenhet av utveckling visste vi vikten av att snabbt få på plats automatiserade processer för exempelvis tester och kodanalys. Samtidigt lärde vi känna produkten i detalj och började prioritera de mest kritiska delarna inför migreringen.  

Arbetet började med grundläggande funktionalitet. Redan här fördes många diskussioner om att inte bara föra över befintlig kod, utan att utmana gamla beslut och leta efter smartare och mer hållbara lösningar. Med ambitionen att bygga ett system för framtiden övervägdes varje beslut noggrant, även om det ibland innebar längre utvecklingstid. Allt med målet att skapa en robust och skalbar plattform.  

Kundmigreringar – den mest kritiska delen  

När vi närmade oss en färdig version av plattformen i .NET och Microsoft Azure blev det dags att påbörja en separat en separat applikation för att hantera migrering av kunder. Syftet var tydligt: att smidigt och effektivt flytta över varje kund från den gamla till den nya plattformen.  

Migreringsappen utformades för att migrera en kund i taget. Den läste in data från den befintliga versionen (BOF1), omvandlade den så att den passade i den nya datamodellen (BOF2), och importerade sedan all data. För kunden var detta en smidig övergång som tog några minuter, varefter de enkelt kunde fortsätta sitt arbete i den nya moderna plattformen.  

Migreringsappen hade några tydliga steg:  

  1. Validera kundens data i BOF1 för att säkerställa att den var migreringsbar.  
  2. Testmigrera data för att kunna köra automatiserade och manuella tester innan en verklig migrering.  
  3. Radera testmigrering för att säkerställa att inga testdata fanns kvar.  
  4. Migrera kunden på riktigt, där all information uppdateras och kunden omdirigeras till sin nya instans i BOF2. 

Första migreringen – ett år av hårt arbete  

Drygt ett år efter att arbetet påbörjades kunde vi med stolthet migrera den första kunden till vår nya plattform.   

Förväntningarna var höga, och teamet var spända på att se hur systemet skulle klara den verkliga prövningen. Med endast någon mindre bugg precis i början kunde den första migreringen genomföras enligt plan, utan några större problem.  

Det var en milstolpe som bekräftade att vår utvecklingsstrategi var framgångsrik, och att den tid och omsorg vi lagt ner på systemarkitektur, datamodeller och processer verkligen betalade sig.   

Sedan dess har vi fortsatt arbetet med att successivt migrera fler kunder till BOF2, och responsen har varit mycket positiv. Den nya plattformen har tagits emot med öppna armar och vi har fått höra från våra användare att både prestandan, stabilitet och nyutveckling har nått nya nivåer. Att se våra kunders smidiga övergång till det nya systemet och hur det har förbättrat deras arbetsflöde har varit en fantastisk bekräftelse på allt vårt hårda arbete och engagemang.  

Vad är gjort? – Teknisk överblick   

Några punkter som vårt utvecklingsteam gjort för att ta Boards on Fire in i framtiden:  

  • Övergång från Ruby on Rails till Microsoft .NET: För att skapa en modern, stabil och högpresterande plattform har vi gått över från Ruby on Rails till Microsoft .NET. Genom denna övergång har vi fått tillgång till ett mer robust ramverk som möjliggör bättre prestanda, säkerhet och skalbarhet. .NET:s moderna arkitektur har gjort det enklare att bygga ett system som är hållbart och framtidssäkrat.  
  • Flytt från Heroku till Microsoft Azure: För att säkerställa högre stabilitet, säkerhet och skalbarhet har vi valt att flytta från Heroku till Microsoft Azure. Azure ger oss en robust infrastruktur som gör det möjligt att hantera ett större antal användare och växande datamängder, samtidigt som det förbättrar säkerheten för våra kunder. Denna flytt har lagt grunden för att kunna skala upp verksamheten tryggt och effektivt i takt med kundernas behov.  
  • Från Ruby WebSocket-driver till Azure SignalR: För att förbättra flödet av realtidsdata och skapa mer responsiva dashboards i applikationen har vi bytt från Ruby WebSocket-driver till Azure SignalR. Denna förändring har ökat prestandan markant och gör det möjligt att skicka och ta emot data i realtid med högre stabilitet och hastighet. Resultatet är en smidigare användarupplevelse, där uppdateringar på dashboards sker omedelbart och arbetsflöden kan optimeras utan fördröjning.  
  • Ny inloggning via Mirosoft Azure B2C: Vi har implementerat ett nytt login-system genom Microsoft Azure B2C för att erbjuda en modern och säker autentiseringsprocess. Med Azure B2C har vi nu en mer pålitlig lösning för hantering av användarinloggningar som stödjer flera autentiseringsmetoder, vilket förbättrar både säkerheten och användarupplevelsen. Denna förändring gör det enklare för kunder att logga in och hantera sina konton samtidigt som vi säkerställer att deras data är väl skyddad enligt de senaste säkerhetsstandarderna. Det ger också möjlighet till sömlös inloggning via SSO (Single Sign On).  
  • Omfattande förbättringar av databasstrukturen: Vi har genomfört stora förändringar i databasstrukturen för att öka prestanda, skalbarhet och säkerhet. Genom att migrera till Azure Database for PostgreSQL Flexible Server har vi kunnat optimera datahantering och svarstider, vilket innebär snabbare och mer effektiva arbetsflöden för våra kunder. Med denna lösning kan vi också skala databasen efter behov, säkerställa kontinuerlig tillgänglighet och dra nytta av inbyggda säkerhetsfunktioner som hjälper till att skydda känslig information. Dessa förbättringar gör plattformen mer robust och anpassningsbar, redo att hantera en större mängd data och användare på ett effektivt sätt.  
  • Segregering av data: För att säkerställa att information alltid hamnar rätt och hålls säker har vi infört en helt ny modell för segregering av data. Med denna modell kan varje kund få sin egen dedikerade databas och sitt eget skräddarsydda lagringsutrymme för filer – vilket ger maximal integritet och full kontroll över all data. 
  • Nytt rättighetssystem: Vårt nya rättighetssystem erbjuder förbättrad kontroll över åtkomst och behörigheter. Till skillnad från tidigare, där rättigheter bara kunde tilldelas på individnivå, kan de nu hanteras både för grupper och enskilda användare. Detta innebär en mycket mer flexibel och kraftfull hantering av roller och åtkomstnivåer, där data kan begränsas eller delas baserat på specifika behov. Det ger kunderna möjlighet att konfigurera sina arbetsflöden mer effektivt, säkerställa att rätt personer har åtkomst till rätt data och förbättra säkerheten i organisationens informationshantering.  
  • Nytt externt API: Vi har utvecklat ett nytt externt API som öppnar upp för kraftfullare integrationer och utökad funktionalitet. Med ett enkelt och väldokumenterat gränssnitt möjliggör API:et smidig kommunikation mellan Boards on Fire och kundernas egna system, vilket underlättar automatisering och anpassning efter verksamhetens behov. 
  • Helt ny filintegration: Genom att nyttja ett par av Microsoft Azures kraftfulla tjänster har vi tagit fram en helt ny lösning för import av data från filer, som gör det enklare än någonsin att föra in data från andra system i Boards on Fire.
  • Byte från Vue States till Pinia: För att förbättra vår frontend-arkitektur har vi bytt vårt state management-bibliotek i Vue.js från Vue States till Pinia. Det Pinia erbjuder är ett mer intuitivt och flexibelt sätt att hantera applikationens tillstånd, med ett enklare API och förbättrad utvecklarupplevelse. Detta byte har lett till snabbare utveckling, bättre prestanda och en mer responsiv applikation.  

Den nya plattformen är skapad för att leva länge, skala upp, och hantera den ökande mängden kunder och data. Vi är stolta över den resa vi har gjort och de förbättringar vi har implementerat för att säkerställa att Boards on Fire kommer att vara en ledande produkt inom digital daglig styrning även i framtiden.  

https://www.datocms-assets.com/56488/1661954976-tobias-runesson-22.jpg

Tobias Runesson

Developer

Händer på Boards on Fire

Senaste från bloggen

Gratis webbdemo

Vi kan berätta allt om Boards on Fire. Men det är enklare att visa. En snabb webbdemo ger dig grunderna i våra lösningar.