Linuxbasert utviklingsmiljø

Innovasjon kommer ikke av seg selv. Legger man til rette for innovasjon gjennom å tilgang og verktøy, så kan mye skje. Her er historien om hvordan et Linuxbasert utviklingsmiljø har vært med på å skape viktige endringer hos SpareBank 1

Ingen liker repetitive manuelle oppgaver. Går vi 5 år tilbake var en stor del av dagen til oss utviklere preget av modifisering av håndskrevet konfigurasjon og manuelle installasjoner av programvare. SpareBank 1 hadde en plattform som var utviklet for kontorapplikasjoner, ikke programvareutvikling. Det var derfor nødvendig å få på plass en utviklingsplattform som var mer lik den applikasjonene våre kjører på i produksjon.

Det manglet ikke på entusiasme blant utviklerne og i løpet av noen uker var første beta i bruk. Plattformen var basert på Ubuntu, og Vagrant ble brukt for å starte miljøet. Allerede i første beta var noen manuelle oppgaver automatisert. Automatisert installasjon av programvare var det første steget på veien mot en bedre hverdag.

Flere og flere utviklere tok etterhvert i bruk plattformen. Entusiasme er som kjent smittsomt og flere og flere utviklere ville være med på å videreutvikle løsningen. Og hva skjedde? Jo, det dukket opp bash- og pythonscript fra øst og vest. Det ble raskt nødvendig å samle all denne innovasjonen i en felles verktøykasse. Bob ble født, og i dag støtter Bob alle typiske oppgaver en utvikler utfører i løpet av en dag. Noe tilsvarende skjedde aldri på vår gamle plattform og grunnen er enkel. Man må ha tilgang til de rette verktøy om det skal innoveres!

Finnes det en triveligere arbeidsplass enn i i3? Mange foretrekker vanlig gnome eller KDE desktop. Valget er ditt! 

 

SpareBank 1 har et stort utviklermiljø, og vi hadde en periode to linuxbaserte utviklingsmiljø. Vi hadde samtidig to verktøykasser. Men konkurranse kan være sunt. Og da vi bestemte oss for å samkjøre miljøene og videreutviklingen, kunne vi ta det beste fra begge løsningene. Samtidig valgte vi å skrive utviklingsplattformen på nytt basert på de erfaringene vi hadde gjort. Fokuset til den nye løsningen var støtte for videreutvikling gjennom en felles intern open-source tilnærming. Alle team og utviklere som ønsker utvidelser eller endringer kan gjøre dette gjennom å legge opp pull-requests. Dette er en modell som har fungert bra for oss, men som kan være sårbar da det ofte vil være noen entusiaster som driver det meste av utviklingen. Terskelen for at nye utviklere kan bidra, kan være høy.

 

I 2014 oppdaget vi Docker. På et Hackathon samme året fikk vi testet ut en containerbasert måte å kjøre applikasjoner på. Med et linux-basert utviklingsmiljø var terskelen for å utforske Docker lav. I løpet av kort tid kjørte alle nettbankapplikasjonene som Docker containere. Vi kunne da også kjøre databaser, lastbalanserere og Apache instanser lokalt. Docker ga oss en plattform å innovere videre på.

Et utviklingsmiljø er veldig levende, og endringer skjer hele tiden. I tillegg til oppdateringer av operativsystemet, gjør vi hyppige endringer på våre egne verktøy. Det er derfor viktig å bygge inn kvalitetssikring. Vi er nå over 100 utviklere som bruker plattformen, og en feil vil derfor få store konsekvenser. Vi har gjort mange tiltak for å sikre kvaliteten.. Plattformen er ikke lenger avhengig av Vagrant, og kjører med RedHat Linux som basis. RedHat har vi god kompetanse på da vi kjører nettbanken på dette operativsystemet. Vi utfører kodegjennomgang på alle endringer i oppsett og verktøy. Vi har også automatiserte  tester som kjøres på hver endring.

 

Når feil skjer, og det skjer fra tid til annen, oppstår det en kollektiv vilje til å finne en løsning. Det eksisterer en holdning om at det er ikke den enkelte utvikler som har gjort endringen som har skyld i feilen. Alle feil skal avdekkes som en del av kvalitetssikringen, og klarer man ikke fange opp feilen der, må vi forbedre kvalitetssikringen. På denne måten forbedrer vi hele tiden løsningen og alle lærer litt mer hver gang dette skjer.

 

Verktøy er en ting, men skal de ha noen verdi for den enkelte utvikler må man ha tilstrekkelig med rettigheter. Dette gjelder så vel lokalt som i produksjon. En hver mangel på tilgang som stopper flyt og bremser lysten til å gjøre endringer, er hindre vi må fjerne. Hver dag forbedrer vi sikringene våre som gjør at vi som bank kan la alle utviklere installere i produksjon så ofte man ønsker. I tiden fremover kommer vi til å investere mye i fjerne barrierer som hindrer flyt gjennom automatisering. Følg med på bloggen for oppdateringer!