.png)
När Miradots Johan Radivoj började sitt uppdrag på rederiet, som är specialiserade på frakt för både företag och privatpersoner, hade de gått från väldigt lite till omfattande digitalisering på bara några år.
– Jag började som infrastrukturansvarig och DevOps-rådgivare i ett team på sex personer. Teamet ansvarade för att utveckla en webbaserad applikation som gav råd till personalen på fartygens brygga, säger Johan Radivoj.
Applikationen som teamet jobbade med hämtade in data på väder, vind, strömmar, vattendrag och andra faktorer som påverkar fartygen och beräknade det mest bränslesnåla körsättet för hela färden. Initialt fanns det tre fartyg som använde applikationen och kort efter att Johan börjat sitt uppdrag skulle två till integreras. Inom 18 månader skulle installationen vara i drift på över 35 fartyg.
– När jag började fanns det pipelines för att leverera applikationen till valt fartyg via en produktionsmiljö uppsatt, per fartyg, på en dedikerad Kubernetes-plattform. Det fanns ingen verifikation eller tester av koden före leverans till varken master branch eller till produktionsmiljön, alla kunde pusha direkt till master. När en eller flera utvecklare kände sig nöjda med utvecklingen av sin funktion gjorde de en merge direkt i master.
Utvecklarna åkte med fartyget i 28 timmar
Varannan vecka försökte teamet leverera en ny release enligt målen för den senaste tvåveckors-sprinten, berättar Johan Radivoj. Då gick tre eller flera utvecklare på fartyget, åkte med i 14 timmar, sov över och åkte 14 timmar hem igen.
– Det hände vid flera tillfällen att det uppstod problem på de här resorna eftersom någon pushat in stora förändringar i master kvällen innan. När de till slut kände sig nöjda, försökte de installera samma release på de andra fartygen vi hade att tillgå, oftast med oväntade resultat och hårdkodningar i en fartygsspecifik branch som landar på skeppet. Det blev snabbt uppenbart för mig att ambitionen att skala från en handfull anställda och tre fartyg, till ungefär samma antal resurser men på 35 fartyg skulle bli helt omöjligt.
Johan Radivoj började fila på hur han kunde hjälpa till genom att införa nya rutiner och arbetssätt. Han föreslog att de skulle ha fartygsunika konfigurationsfiler så att de inte behövde ha stöd för tre olika applikationer.
– Jag rekommenderade att master-branch låstes. Ingen fick merga in kod direkt till master utan att det landar i en pull request som har godkänts av en kollega i teamet.
När det här var på plats införde han verifikation av koden. Om det kom en pull request säkerställde den så att vedertagna och överenskomna kodstandarder och formatering följdes. Det gjordes även en säkerhetsanalys av koden så att inte typiska säkerhetshål fanns eller att kodbasen använde sig av korrupta eller osäkra bibliotek.
– Det gick att hoppa över det här steget vid behov, men då blev det tydligt uppmärkt att det hade skett och vem som gjort det.
Varje ny funktion skulle ha ett minimum av tester
Johan tog tillsammans med en av utvecklarna i teamet ansvar för att varje ny funktion skulle ha ett minimum av tester enligt de krav som funktionen haft under det agila utvecklingsarbetet. Det här gjorde att det kändes tryggare att säga att en funktion faktiskt var levererad, men också försäkra sig att det inte förstört tidigare funktioner utan att behöva göra en halv eller ibland hel dags manuellt testande.
– Här någonstans insåg vi att vi inte längre behövde de extremt dyra release-dagarna på båten. Vi kunde släppa en release till alla båtar samtidigt med tryggheten att den var helt och hållet funktionell.
När testerna fanns på plats införde Johan open source, OS-agnostiska verktyg som han bundlade med repot så att utvecklarna med ett fåtal instruktioner kunde inkorporera det i sin miljö och köra, vissa eller alla, tester lokalt. Det här blev som ett försteg till en ”git commit” eller ”git push”.
– Ett återkommande problem jag upptäckte var att utvecklarna var vana vid en traditionell applikationsutveckling där det finns en gigantisk binär som exekveras inuti en virtuell maskin. De var varken intresserade av eller hade tiden att lära sig värdet med Kubernetes.
Johan förklarar att det här skapade dialoger som ofta såg ut enligt:
"Varför är båt X trasig?"
"Hur är den trasig?"
"Ja koden funkar på min dator men inte i plattformen på skeppet"
"..."
– Jag undersökte och tog fram verktygen som behövdes för att de skulle kunna simulera hela plattformsuppsättningen lokalt i sin egen dator. Istället för att köra ”python binär.py” hade de nu koden i en container-baserad Kubernetesmiljö och varje gång de sparade koden i sin IDE laddade verktyget om så att deras sparade ändring nu var det som exekverades.
Centraliserade loggar – lätta att komma åt och söka i
Nu hade en hel del effektiviserats och förbättrats, men det fanns fortfarande ett väldigt tidskrävande och manuellt sätt att arbeta för att verifiera specifik funktionalitet som utvärderade beräkningarna gjorda över en genomförd resa. Den här verifiering berodde på specifika syslog-meddelande och att invänta utförandet av en hel resa.
– Jag integrerade så att vardera plattform skickade plattforms & applikations-loggar till Azure, utbildade utvecklarna så att de själva kunde söka i loggarna och lägga till larm vid särskilda loggmeddelande. Det här gjorde att vi kunde ha ärendehantering på plats innan användarna felanmälde till oss.
Tillsammans med en nyanställd senior utvecklare tog Johan fram ett sätt att spela in den data som inhämtas under fartygets resor och spela upp den lokalt. På så sätt skapades en likvärdig baseline för att köra tester eller verifikation av nya funktionaliteter.
– Det här gjorde det möjligt att skapa en staging-miljö där vi inför en release kunde testa helheten för att sedan leverera verifierad kod till fartyget som tidigare varit första testbåt. Vi minskade supporttiden uppåt 80% procent och fick betydligt nöjdare användare, samtidigt som vi även minskade tiden för utveckling och verifikation. Plötsligt kunde teamet leverera mer och snabbare.
Slutligen automatiserade Johan uppsättning och leverans av infrastrukturen så att uppåt 20 fartyg var integrerade med var sin plattform.
– Det här gjorde att teamets icke-tekniska SCRUM-master med några knapptryckningar kunde välja version av Kubernetes och genomföra uppsättning av de kvarvarande 15 fartygen allt eftersom de fick hårdvarustöd för vårat paket, det som tidigare var del av mitt ansvar att utföra, avslutar Johan Radivoj.
🔴 Före
- Inga funktionstester
- Inga integrationstester
- Inga säkerhetstester
- Manuell kodverifikation
- Manuell utrullning (fartygs-agnostisk)
- Manuell utrullningsverifikation
- Ingen loggning
- Inget sätt att reproducera resor eller buggar
- Två olika arbetssätt
- ”Traditionell" utveckling av två monorepo för backend och frontend, med vardera binär, körandes lokalt
- ”Översättning" av föregående till att passa in i en Kubernetesutrullning, samt felsökning därav
- Manuell installation av vardera miljö
- Inkonsistent miljö med olika releaser utrullade, utan överskådlighet
✅ Efter
- Integrerade funktions-, integrations- och säkerhetstester före kod hamnar i master och i produktion på fartyg
- Automatisk utrullning och verifikation
- Plattforms och applikationsloggar centraliserade och lätta att komma åt
- Möjlighet att reproducera specialfall för felsökning och förståelse
- Ett enhetligt arbetssätt i produktion som utvecklingsmiljö