Automatisk test och kontinuerlig leverans

Under ett antal år har jag varit med och lagt grunden till många system och utvecklingsmiljöer där automatisk test och build pipelines utgjort viktiga element. Jag har även haft förmånen av att ha arbetat i teamen under en längre tid efter etableringen och den vägen erhållit praktisk erfarenhet av dagligt utvecklingsarbete där automatisk test och täta leveranser ingår.

IMG_20150331_173153

Jag har gjort liknande observationer som Jez Humble gjort och på ett utmärkt sätt beskrivit i boken Continuous Delivery.

För att automatisk test ska kunna fungera och underhållas över tid måste den integreras på ett bra sätt i den normala byggcykeln. Alla utvecklare och testare ska enkelt kunna köra testerna innan commit, och på samma vis som byggpipelinen gör. Testkod och testdata ska självklart också vara incheckat. Alla i teamet oavsett om man jobbar med applikationsutveckling eller testutveckling ska kunna rätta och utveckla testerna. Testerna ska köras automatiskt vid incheckning i kodrepot och om testerna fallerar avbryter man det man höll på med och avhjälper felet. Av detta följer att testutvecklare och applikationsutvecklare måste samarbeta om aktiviteterna.

Om testutveckling sker separat från applikationsutveckling och testutvecklingen ligger före applikationsutvecklingen kommer det alltid att finnas tester som fallerar eftersom funktionaliteten som testas inte är utvecklad än. Och om testutveckling istället ligger efter applikationsutveckling i fas är det stor risk att systemet som utvecklas inte blir testbart. Och under tiden applikationen och automattesterna inte är synkade så är systemet inte releasebart. Alla dessa situationer är oönskade.

De utvecklingsmiljöer jag etablerat de senaste åren har varit Maven-baserade och uppdelade i flera moduler. Den första uppdelningen är en applikationskatalog och en testkatalog. Under testkatalogen lägger jag moduler med olika automatiska tester, uppdelade per verktyg/ramverk samt tjänstestubbar, testdatamoduler m.m.

De vanligaste verktygen för automatisk test jag stött på är:

SoapUI Pro är rätt använt ett bra verktyg för att utveckla automatiska tester mot tjänstegränssnitt.

Selenium fungerar bra så länge man håller sig till smoke-tester av UI där och inte försöker sig på att skriva funktionella tester med anspråk på att täcka upp stora delar av systemets funktionalitet.

Java är fortfarande ett enkelt och effektivt verktyg att skriva funktionella tester med. Man skriver dem med JUnit-ramverket precis som med vanliga enhetstester, men koden kör mot det riktiga systemet som deployas via Maven i Mavens byggcykel. Om man är van vid Groovy istället för Java (i SoapUI använder man Groovy för lite mer avancerade saker) så är det lätt att lägga till en Groovy-modul istället, och fortfarande på JUnit-ramverket och med tillgång till samma stödbibliotek som i Java.

Cucumber fungerar bra och resulterar i trevlig och lättändrad kod, och sympatisk och lättläst rapportering med bra integration i Jenkins via Cucumber plugin. En risk som jag och flera omkring mig också observerat är att man från verksamhetssidan inte tar tillvara på fördelarna som en exekverbar kravspec på den här formen innebär och då blir det bara utvecklare som läser och uppdaterar den vilket innebär att man då lika gärna kan skriva dessa tester direkt i Java eller något annat programmeringsspråk.

För kapacitetstester är JMeter är ett verktyg jag nyfiken att undersöka vidare hur man lämpligast integrerar med Maven och hur det fungerar i längden. LoadUI är ett annat alternativ här som jag ännu bara kört manuellt, alltså ännu inte integrerat i en pipeline.

Spring Boot har jag använt många gånger för att skriva mer eller mindre avancerade tjänstemockar som krävs för automatisk test, både REST- och SOAP-servrar. Mycket effektivt och ändamålsenligt för detta.

Och sist men inte minst: Lamporna

Utan lampor eller liknande synlig och central indikator är det lätt att teamet efter den inledande CI-förälskelsen glömmer CI-statusen och att testjobb fallerar i veckor i sträck.

En för många ny aspekt av automatisk test är att testledaren bör ha kontroll på alla tester, oavsett om de är manuella eller automatiska, och oavsett vem i teamet de är utvecklade av. Gränsen mellan applikationsutvecklare och testutvecklare ska helst vara flytande eller obefintlig.

Om man har krav på sig att följa upp testtäckning mot krav måste detta också ske kontinuerligt, vilket kräver intrimmade procedurer och koll på krav- och testläget.

Vidare ska testledaren ha kontroll på vilka tester som implementeras automatiskt och i vilken modul och vilka som är manuella, ha en idé om vilka manuella tester som ligger på kö för automatisering och ta initiativ till och följa upp att så sker.

Levererar man ofta så behöver man inte ha samma kontroll på aktuell teststatus som annars, eftersom normalläget är att alla tester passerar, lampan är normalt grön. Merparten av testerna måste då vara automatisk och den manuella delen får inte ta lång tid att plöja igenom.

Levererar man till exempel varannan vecka kan man kanske kosta på sig en dags manuell test innan produktion, levererar man varje dag rör det sig kanske om någon timme. Får man en tillräckligt inoljad utvecklings- och leveransmodell slutar man kanske helt att ha en manuell testprocedur innan produktionssättning eftersom man lärt sig att utveckla och testa i små steg från början. Ett extra teststeg på slutet blir då redundant. Och inträffar fel i produktion är man vaken och fixar snabbt felet och skickar ut en rättning. Det går ändå inte att skydda sig helt från produktionssmällar eftersom våra användare och externa system ibland gör helt andra saker än vad vi tänkt oss som ingen testning i världen kan förutse. Bättre då vaka över systemet i drift och att göra det enkelt att skicka ut en rättning. Detta kräver i sin tur en väloljad pipeline hela vägen ut i produktion och nära samarbete med driften. I detta avseende har många fortfarande en bra bit kvar att vandra.

Men å andra sidan, att det finns mycket kul saker kvar att göra är underbart för alla oss som älskar det här jobbet :-)

Publicerad i Continuous Delivery, DevOps, Java, Test

Summering av Jfokus 2015

Inte heller 2015 blir ett sannolikt år för robotarnas övertagande. I sessionen Creating Our Robot Overlords: Autonomous Drone Development vi fick konstaterat att en AR Drone 2.0 inte klarar att bära en Raspberry Pi med batteri och därmed får fortsätta att flyga ointelligent, eftersom att hjärnan fått lämnats kvar på marken. Men inte bara därför – den intelligenta programvaran saknades också.

IMG_20150203_090941

Läs mer ›

Publicerad i Continuous Delivery, DevOps, Java, Uncategorized

Den sista MacBook:en i sitt slag

Mitt MacBook-liv började år 2011. Året därpå hade jag sönder den mekaniska hårddisken, så jag monterade istället en pirat-SSD och ominstallerade OS:et. Året efter det tog utrymmet på den disken slut (500GB) och jag ersatte den sedan länge oanvända och meningslösa optiska enheten med ytterligare en SSD på 1TB. Med 16GB RAM och 1.5TB disk gjorde den sedan susen under lång tid.

Efter att MacBook:en gjort tjänst varje dag i 4 år, började först grafiken spraka till och gjorde så oftare och oftare till dess hela skärmen blev randig och datorn låste sig. Till slut gick den inte ens att starta om.

IMG_20150118_193842

 

Läs mer ›

Publicerad i Java, OS X

Blue Green Deployment

Samarbetet kring vår open source Continuous Delivery Build Pipeline fortsätter i mobbprogrammeringsform. Den här gången bjöd Mikael Sennerholm in till Avega-kontoret på Östermalm eftersom det ryktades att någon en gång hade sett att man minsann kunde locka fram riktigt bra fart i det nätverket.

Vägen till DevOps-nirvanat visade sig gå genom att gräva fram det gamla sladdnätverket igen och plocka upp sin gamla RJ45-utrustning igen från längst ned i byrålådorna hemma, för Wifi fungerar fortfarande inte bra nog för att ladda ned alla maskinavbildningar på rimlig tid.

Men Avega är i gott sällskap, det tog år av tjat innan CAG fick ett på riktigt fungerande Wifi-nät med flås på Kista-kontoret. Så det borde väl inte vara helt omöjligt att få till det på Avega heller så småningom.

IMG_20150120_185748

Läs mer ›

Publicerad i Continuous Delivery, DevOps

Infrastruktur som kod

Docker är nästan magiskt. Hur går det till när Docker startar upp en maskin och ett kommando på den maskinen på bara en bråkdel av en sekund?

Men förr eller senare vänjer man sig även vid magi, och Mikael Sennerholm från Avega och jag gjorde till slut en kurs av det, där vi under en heldag gick igenom bland annat Docker, men även Vagrant och Thoughtworks Go. Träning på olika smaker av Linux följde med på köpet. Mikael höll kursen och jag hjälpte till med labbarna.

Screen Shot 2014-11-24 at 22.47.19

 

Läs mer ›

Publicerad i Cloud Computing, Continuous Delivery, DevOps, Java, LinkedIn, Linux

OS X Yosemite för Javautvecklare

Jag uppdaterade min Macbook till Yosemite idag och stötte bara på två små saker. Precis som vid uppdateringen till Mavericks så avinstallerar Apple Java 6. Det medför att IntelliJ inte startar efteråt, då dess launcher är hårdkodad att använda Java 6. Dessutom ser fonterna ut som skit rent ut sagt om man kör IntelliJ på en modern Java från Oracle.

Lösningen är att återinstallera Java 6 från Apple.

Den andra grejen var att Xcode behövde en refresh – av någon anledning hittade inte min installation command-line tools längre. Lösningen:

sudo xcode-select -r
sudo brew update

Efter att man godkänt licensavtalet för Xcode så fungerar Homebrew igen. Att använda sudo här är en engångsgrej efter uppdateringen till Yosemite. Givetvis ska man aldrig använda sudo för att köra brew i vanliga fall.

Ovan gällde för min maskin som hade fulla Xcode installerat sedan tidigare. När jag uppdaterade min nya maskin som bara hade command line tools, så fick man helt enkelt installera om dem:

xcode-select --install

På den maskinen har jag dessutom gått över till att köra Git från Homebrew, så där behövdes ingen uppdatering av command line tools för att göra brew update.

Publicerad i Java, OS X

Automatiskt byggnummer

Varje gång vi bygger en releasekandidat av systemet, deployar till en testmiljö eller kanske bara behöver en version vi vill kunna referera till i exempelvis felrapporter, ska bygget ges ett unikt versionsnummer.

Ett versionsnummer kan vara ett enkelt löpnummer eller kanske bygga på semantic versioning (1.2.42).

Det är praktiskt att tillgängligöra versionsnumret på ett antal olika sätt: Som inspekterbar i artefakten själv i MANIFEST.MF, i Mavens pom-versioner, maskinläsbar i runtime, till exempel i en endpoint /appversion i ett REST-gränssnitt eller synligt i användargränssnittet.

Screen Shot 2014-09-22 at 22.33.23
Läs mer ›

Publicerad i Continuous Delivery, Java, Uncategorized

Den nya nollnivån

Arbetet relaterat till Continuous Delivery har lett oss till en allt tydligare insikt om den grundfunktionalitet som bör finnas på plats i en kör- och utvecklingsmiljö redan från start, för att vi direkt ska kunna börja producera funktionalitet relaterad till kundnytta utan att börja ackumulera teknisk skuld.

Denna utvecklings- och körmiljö kan man också kalla Build Pipeline. Den omfattar såväl verktyg runtomkring systemet i fråga (till exempel Jenkins, Gradle eller Maven) som aspekter av själva systemet. En Build Pipeline av denna typ är att sträva efter såväl om man levererar systemet varje dag som en gång per kvartal.

Summan av den grundfunktionaliteten är vad jag här betecknar som nollnivån.

level-of-zero

 

Läs mer ›

Publicerad i Continuous Delivery, DevOps, Java, Test

Bash git-prompt för OS X eller Linux

Om man kör med git så blir man förr eller senare intresserad av att köra det mesta via kommandorad. En sak man då kan sakna är överblicken över det lokala repot – vilken branch står jag i? Har jag några inkommande/utgående förändringar? Är något lagt på stash-stacken?

Det finns ett utmärkt Githubprojekt som löser problemet genom att ge en mer informativ bash-prompt och som dessutom asynkront kör git status när man trycker retur. Jag har kört med den här lösningen i över ett år och det är numer det första jag installerar på en ny maskin.

För att installera detta i sin hemmakatalog så kan man göra följande:

Läs mer ›

Publicerad i DevOps, Linux, OS X

Continuous Delivery Pipeline med docker

Igår återsamlades vi en liten grupp DevOps-intresserade konsulter från flera olika konkurrerande bolag för att gemensamt bygga vidare på vår build pipeline. Den här gången höll vi till i CAGs lokaler inne i city.

IMG_20140604_201356[1]

Huvudtemat för dagen var docker. Idén var att införa docker som provider till Vagrant i vår build pipeline. docker innebär att nya maskiner blir betydligt mer lättviktiga än om varje maskin är en egen virtualbox-instans som vi hittils kört med Vagrant.

Läs mer ›

Publicerad i Continuous Delivery, DevOps, Java, Linux

Kategorier

LinkedIn Auto Publish Powered By : XYZScripts.com