Hur kan tillvaron avseende verktyg i ett utvecklingsteam se ut, specifikt om teamet och organisationen arbetar enligt en devops-modell? Det finns en mängd verktyg att tillgå, men hur hänger de ihop och i vilken mån behöver du bry dig om eller förstå hur de hänger ihop?
I den här artikeln går vi igenom vilka typiska verktyg vi stött på i team som vill leverera ofta.
Vi tycker osss höra ordet något mer sällan nu än för några år sedan. Det beror nog inte på att populariteten minskat utan snarare att allt fler redan påbörjat eller avslutat resan mot devops. Däremot pratas det mer om att kunna göra release och deploy ”oftare”, vilket i praktiken är det många menar med uttrycket devops.
Utan att gå in på detaljer känns det viktigt att nämna hur devops utförs i praktiken ser olika ut för olika team. För vissa ska varje ”commit” direkt ut i produktion men för de flesta sker en uppsamling allt från dagligen upp till varannan vecka av olika verksamhets-orsaker.
Längst ner i artikeln hittar du verktygen mappade för respektive del i DevOps-kedjan.
Att skriva och hantera kod professionellt innebär att ett val av versionshanteringssystem måste göras om det inte redan är gjort. Idag används git i princip överallt och då ofta i form av produkterna bitbucket eller github där det går att skapa konton och kollaborera.
Det finns fortfarande de som använder till exempel subversion men i ett nytt projekt är git mer eller mindre de facto-standard.
Git: https://git-scm.com/
GitHub: https://github.com/
Bitbucket: https://bitbucket.org/
Subversion: https://subversion.apache.org/
Syftet med ett versionshanteringssystem är i grunden det som namnet antyder, att hantera och spara gamla versioner av koden för att kunna analysera och återskapa äldre versioner. Men en fundamental aspekt är också vilken ”branch-strategi” som väljs. Detta för att flera personer på bästa sätt ska kunna producera kod parallellt och sedan få ihop det inför leverans. Vi kommer inte att gå igenom ämnet här utan vill bara peka på vikten av att fördjupa sig i det. Val av branch-strategi är inte i första hand ett verktygsval men bör behandlas med samma signifikans som när du väljer verktyg.
Att bygga, det vill säga göra ”build” innebär också val av verktyg.
Det är ofta olika ”triggers” i versionshanteringssystemet som används för att sparka igång byggen. Till exempel kan triggers definieras tillsammans med kommandot git push. Idén är att deploy-processen endast ska fortsätta om bygget inklusive tester och analyser går igenom och accepteras.
Verktyget som skapar körbara moduler bestäms vanligtvis av vilket programmeringsspråk som används. Men det finns många val när det kommer till att enhetstesta koden och bygget. Vi betraktar utförandet av enhetstester som en del av bygget.
NUnit: Används för .NET-språk . Härstammar från JUnit.https://nunit.org/
xUnit: Öppen källkod. För .NET-språk. https://xunit.net/
JUnit: För Java. https://junit.org/
TestNG: För java. Inspirerat av JUnit och NUnit men med fler funktioner. Används även till andra typer av tester än enhetstester.https://testng.org/
Under bygget utförs ibland även statisk kodanalys av verktyg som till exempel sonarQube.
sonarQube: Kontrollerar kodkvalitet statiskt. https://www.sonarqube.org/
När bygget väl gått igenom kommer vi att vilja utföra andra steg som att deploya på testmiljöer och utföra andra typer av tester. Det är då läge att nämna begreppet Kontinuerlig Integration, eller ”Continuous Integration” som vi säger på ren svenska. Det kan beskrivas som att det vid givna operationer ”rasslar till” och triggar ytterligare automatiska steg som i sin tur ser till att allt hänger ihop på ett bra sätt. Detta brukar liknas vid en pipeline och kräver också sitt verktygsval.
Vill för övrigt hellre kalla ”pipeline” för ”assembly line” där bygget bara är en av de första stationerna på denna ”assembly line”. Men för enkelhetens skull använder vi begreppet pipeline framöver.
I en pipeline är det en hel del som normalt skriptas, antingen i klassisk ”shell scripting” som till exempel bash eller i något annat skriptspråk som Powershell.
Powershell: Kan köras på antingen Windows, Linux eller macOS. Detta är trevligt om vi driftar mer än en typ av dessa miljöer. https://docs.microsoft.com/sv-se/powershell/scripting
Hur vi har valt att drifta lösningen i slutändan påverkar hur driftsättningen går till i hela kedjan och om vi till exempel använder en container-teknologi som Docker eller inte. Detta är ytterligare en aspekt vi bara nuddar vid här men som också är värd att känna till och fördjupa sig i.
Docker: https://www.docker.com/
Det finns orkestreringsverktyg som underlättar driftsättning. Två exempel är Kubernetes och varianter som OpenShift som kan hantera
Docker-containers.
Kubernetes: https://kubernetes.io/
OpenShift: https://cloud.redhat.com/learn/what-is-openshift?hsLang=en
För utveckling i Java är Jenkins och Maven nedan vanliga verktyg.
Jenkins: För pipeline. https://www.jenkins.io/
Maven: För bygge egentligen. Men nämner det här i samband med CI för att Maven även hjälper till att strukturera upp projektet. https://maven.apache.org/
I jämförelse med Jenkins känns GitHub Actions och Bitbucket Pipelines enklare att komma igång med och arbeta med.
Exempel på vanliga pipeline-verktyg:
GitHub Actions: https://github.com/features/actions
Bitbucket Pipelines : CI/CD-pipeline från Atlassian. Kan köras som ”software as a service” till skillnad från Bamboo.https://bitbucket.org/product/features/pipelines
Bamboo: En till CI/CD-pipeline från Atlassian. Det här är en av de mer lättanvända men fortfarande kraftfulla vi jobbat med. Ska enligt uppgift numera endast finnas som ”on premise” och är mer integrerad med Atlassians övriga produkter än Bitbucket Pipelines. https://www.atlassian.com/software/bamboo
Azure Pipelines: En del av Azure DevOps. https://azure.microsoft.com/en-gb/services/devops/pipelines/
TeamCity: https://www.jetbrains.com/teamcity/
CircleCI: https://circleci.com/
Tester i allmänhet kan utföras i flera om inte i alla steg från ax till limpa under bygget. Här sätts strålkastarljuset på verktyg för de tester som utförs när något driftsatts i en miljö som antingen är en testmiljö eller kanske själva produktionsmiljön. Det kan också innefatta tester på utvecklarens egen dator efter att ha spunnit upp en server lokalt.
Testverktyg för att automatisera och likna användarinteraktioner med webb-läsare. Vi har nämnt några av dessa fördjupat i tidigare artiklar.
Selenium: Originalet. Automatiserar browsers, inte nödvändigtvis bara för test. https://www.selenium.dev/
Cypress: Utvecklarnära. https://www.cypress.io/
Testcafe: Mer “end to end”-fokus. Ren Node.js. https://testcafe.io/
Protractor: För att testa web-applikationer byggda med angular. https://protractor.angular.io/
Playwright: Någorlunda nytt. Intressant att ta i beaktande om ett val av verktyg ska göras. Samma personer som låg bakom Puppeteer ska ligga bakom detta. https://playwright.dev/
Nedan följer exempel på testverktyg och ramverk för att automatisera api-anrop. Det finns ingenting som hindrar att denna typ av tester skrivs i ren kod av något slag som till exempel i Python. Det kan också finnas hjälpramverk i sådana fall som med exemplet Mocha för Node nedan.
SoapUI: Används sedan länge av många. Stödjer fler protokoll än bara Soap. https://www.soapui.org/tools/soapui/
ReadyAPI: Härstammar från samma företag som gjort SoapUI, dvs Smartbear. Har inte använt det själv men är enligt information mer integrerbart med pipelines och kan också användas för att lasta. https://support.smartbear.com/readyapi/
JMeter: Ett klassiskt verktyg för prestandatest och kan användas till mycket. https://jmeter.apache.org/
Postman: Ett klassiskt verktyg för att snabbt testa api’er manuellt. Har med tiden blivit allt mer avancerat. Nu för tiden finns även Newman som kan köra postman-kollektioner via skript. https://www.postman.com/
Mocha: Ett exempel på Node.js-ramverk för test. Det finns en uppsjö av paket som går att använda för själva rest-api-anropet om det nu är rest som ska testas. Dessa paket är förvisso inte direkt relaterade till just Mocha. Ett exempel av många på att kunna göra api-anrop är via Chai-http som i sin tur går hand i hand med Chai Assertions Library. https://mochajs.org/, https://github.com/chaijs/chai-http#readme, https://www.chaijs.com/
För att publicera och tydliggöra testresultat finns integrationer av olika slag till tidigare valda verktyg i kedjan.
Det finns kopplingar från pipeline-verktyg till Teams och Slack. Det går att göra egna ”dashboards” i verktyg som Jenkins och Azure. Ett varningen finger är att det kan bli rörigt och en viss underhållsbörda om samma testresultat skickas åt många olika håll. Om resultatet går till en enda kanal eller en enda anslagstavla lär vi oss att titta just där och det blir ett tydligt ”go to”-ställe.
Det vill säga ”Continuous Delivery” eller CD, handlar om att driftsätta i både testmiljöer och i produktion med större mått av automatik. Detta innebär att fler kan tänkas ha åsikter om vad som är lämpligt att göra och när det ska göras. Vår egen reflektion i sammanhanget är att det handlar om förtroende. Om utvecklingsteamet kan visa på förutsägbarhet och kvalitet kommer affärsverksamheten att få förtroende och våga släppa sargen. Då kan vi leverera oftare och kanske till och med driftsätta med friare tyglar.
I princip är alla verktygsval redan gjorda och det handlar mer om hur långt organisationen vill att automationen ska gå.
Det finns också verktyg för att monitorera och läsa loggar. Ofta skapas loggfiler distribuerat på flera olika servrar och då är det trevligt att få en konsoliderad bild. Exempel på verktyg:
Splunk: https://www.splunk.com/
Kibana: Presentationsdel för att visualisera data från Elasticsearch.
https://www.elastic.co/kibana/https://www.elastic.co/elasticsearch/
Datadog: https://www.datadoghq.com/
Grafana: Liknar Kibana, gör presentationsdelen. https://grafana.com/
Det finns många verktyg och många sätt att göra saker på. Ämnet i sig är ett rörligt mål och vi är bra rustade för förändring genom att konstant hålla ögonen öppna och dela information och erfarenheter mellan oss. Genom att ta del av exemplen i denna artikel hoppas vi sprida ljus över hur det går till i många utvecklings-team just idag.