Det skal være lett å gjøre rett — del 2

Ola Hast
Ola Hast
Oct 5, 2020 · 6 min read

Vi har valgt å lage en rekke verktøy som gjør livene våre enklere. Disse hjelper oss med å sette opp utviklingsmiljø, deployment og andre vanlige arbeidsoppgaver. Som vi var inne på i første del av denne artikkelserien har vi sett at dette gir oss både fart, trygghet og god nattesøvn. Et skikkelig kinderegg! Men hvordan kom vi egentlig i gang?

Alle må starte en plass

Da vi startet vår reise som verktøymakere, hadde vi et likt utgangspunkt som veldig mange andre bedrifter: En nedlåst Windowsplattform med Office og IE forhåndsinstallert, men dessverre ikke så veldig mye mer. Og du hadde heller ikke rettigheter til å installere noe selv. Dette er et veldig rasjonelt utgangspunkt om man ikke skal drive med utvikling.

Bare det å få satt JAVA_HOME var i seg selv en utfordring, siden maskinen både titt og ofte fikk miljøvariablene resatt av administrasjonsverktøyet. Hele prosessen med sette opp og vedlikeholde et fungerende utviklingsmiljø var en frustrerende affære, som også gjorde det veldig vanskelig å teste ut nye ting. Utviklere brukte ofte ukesverk på å få satt opp alt og på å bli produktive medarbeidere.

Dette gjorde at vi ble kjent med våre to første venner: Virtualbox og Vagrant.

Kilde: medium.com/@botdotcom/installing-virtualbox-and-vagrant-on-windows-10

Kombinasjonen av Virtualbox og Vagrant ga oss muligheten til å scripte oppsettet av et virtuelt linux-miljø uten å måtte forlate windows-plattformen. Da tok det ikke lang tid før vårt første hjemmelagde verktøy, provision-dev ble født.

Nå har vi forlatt windows helt til fordel for en utviklingsplattform som kjører Linux, men verktøyet provision-dev lever videre.

Provision-dev

Provision-dev er et konfigurasjonsrepo som lar oss velge selv hva vi ønsker å installere på maskinene våre. Sett utenfra så inneholder provision-dev to script.

Configure.sh lar deg velge hva du vil installere i utviklingsmiljøet. Det kan typisk være hvilken versjon av Intellij man ønsker. Videre kan man velge om man ønsker å installere verktøy for sikkerhetstesting, databaseverktøy, mobilutvikling osv.

configure.sh brukes til å velge hvilke verktøy man ønsker å installere i sitt miljø

Når man har valgt hva man ønsker i utviklingsmiljøet sitt så kjøres steg to av provision-dev, nemlig provision.sh.

Provision.sh setter opp alt du trenger for å gå fra en nytanket laptop med linux til å ha et fullt fungerende utviklingsmiljø med et utvalg Java-versjoner, Maven, Node, IDE og kode-editorer. Samt en rekke ekstraverktøy som ikke alle nødvendigvis trenger. Men det er likevel viktig at spesialistene også slipper å bruke masse tid på å sette opp sine verktøy.

Dette gjør at du i løpet av få timer fra du får utlevert en maskin, kan ha et ferdig oppsatt utviklingsmiljø. Og vi har som mål at alle nye utviklere skal gjøre sin første commit mot master i løpet av første dag.

Bob

Bob er også en viktig del av plattformen vår. Av en eller annen grunn så virker det som at utviklere er fascinert av Byggmester Bob og de andre karakterene i serien. Som regel ender det opp med at interne verktøy får sine navn derifra.

Kilde: Youtube

Vår Bob startet som en rekke script som ble brukt til å bygge nettbank-applikasjonene, derav navnet Byggmester Bob. Etterhvert samlet vi disse scriptene i et felles gitrepo, slik at vi enklere kunne holde de like på tvers av utviklermaskinene. Som en ekstra bonus så bruker vi provision-dev til å sette opp en cron-job som sørger for at Bob alltid er oppdatert med de siste forbedringene som er gjort.

I løpet av de sju årene siden første commit, så har Bob fått mange flere ferdigheter. Vi bruker nå Bob til blant annet å håndtere lokalt utviklingsmiljø, deploye til OpenShift og sette opp byggejobber.

Bob har flere funksjonsområder

Bob er et verktøy du bruker fra kommandolinjen. Kommandoene og strukturen er inspirert av git, og både autocomplete og dokumentasjon av kommandoene er tilgjengelige fra terminalen. Kommandoene er gruppert etter funksjonsområde slik at det er lett å bruke og finne fram. Det er viktig for at det skal bli brukt.

Bob og provision-dev utgjør basisen blantverktøyene våre og er de vi bruker mest i hverdagen, men de er ikke alene.

Generering av applikasjoner

I SpareBank 1 Utvikling er vi nå i overkant av 20 team som jobber med å lage stadig bedre nettbanktjenester til kundene våre. Og for at de skal kunne gjøre det, så må de kunne jobbe uavhengig av hverandre. Samtidig så skal vi kjøre et stort antall applikasjoner i containere og da ønsker man at mye er løst standardisert måte.

Et godt eksempel på dette er logging. God logging er viktig av mange årsaker, og en god kandidat for standardisering. Det gjør livet enklere både for deg som utvikler og andre som har behov for å se i loggene. Og hvis man bruker verktøy som ELK-stacken, Splunk eller Humio kan man lettere søke på tvers av applikasjoner og få et bedre oversiktsbilde over applikasjonene dine.

For å sørge for at alle som skal lage en ny applikasjon hos oss har et likt utgangspunkt har vi tatt i bruk applikasjonsgeneratorer. Bruk av en slik generator kan bidra til å fjerne en del yak-shaving:

  • Oppsett av logging

I tillegg så gjør dette det mulig for oss å sørge for at applikasjonene kommer med ønskede sikkerhetsmekanismer innebygd.

Det finnes flere verktøy du kan bruke. Av de enkleste så har man create-react-app og Spring-initializr. Vi hadde bruk for å lage noe litt mer tilpasset til vårt miljø, så derfor valgte vi Yeoman.

Yeoman er et kommandolinjeverktøy som gjør det enkelt å kjøre generatorer. Det er basert på Javascript og Node slik at det fungerer fint på de fleste maskinplattformer. Det finnes også et utall ferdiglagde generatorer som man kan ta i bruk, eller man kan gjøre som oss, og lage en som er tilpasset din organisasjon.

Her er et eksempel fra awl-generatoren vår. AWL står for Alliansens weblag og er templatene vi bruker til å lage apier og andre applikasjoner som er eksponert mot internett. Her har du mulighet til å velge hva slags type applikasjon det er og så får du et utgangspunkt med riktig konfigurert sikkerhetsnivå og frontend-modul ved behov.

Fallgruvene

Verken standardisering eller verktøy som Bob er uten fallgruver. Og de bør man være klar over.

Bob er en abstraksjon på toppen av en rekke verktøy. Det positive med abstraksjonen er at man forenkler mange operasjoner som i utgangspunktet er komplekse. Da slipper man å sette seg inn i hvordan det fungerer under panseret og man får utført det du ønsker å oppnå. Baksiden med dette er at det ikke alltid er lett å forstå hva som skjer. Derfor kan verktøy bli brukt feil og det kan bli vanskelig for brukerne å feilsøke hva som gikk feil de gangene det ikke fungerer som forventet. Abstraksjonene bør derfor være på riktig nivå og heller kombineres i et byggescript.

I tillegg så tror vi at det er viktig at verktøyene er åpne. Dersom noen lurer på hvordan det fungerer under panseret, må koden være lett tilgjengelig og det må også være mulig for alle å bidra i utviklingen. Dette er noe vi skal skrive mer om i en senere artikkel.

I del tre av denne serien skal vi se mer på hva vi har gjort for å gjøre produksjonssetting raskere, tryggere og hvordan det også bidrar til god nattesøvn.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for

Ola Hast

Written by

Ola Hast

Utvikler i SpareBank 1 Utvikling

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for