Amazon, LinkedIn, Netflix, Etsy, Microsoft og mange flere af de store gør det. Men hvorfor er der ikke endnu flere der allerede har taget Continuous Integration til sig?
Onsdag 20/09/17 gav Jesper Wermuth fra Lund&Bendsen en kort introduktion til udviklingskonceptet Continuous Integration. Foruden en gennemgang af hvad Continuous Integration går ud på, var fokus på hvorfor og hvordan Continuous Integration bør og kan implementeres. Samtidig fik deltagerne mulighed for at stille relevante spørgsmål i forhold til de udfordringer de selv sidder med til dagligt.
Hvad er Continuous Integration?
Jesper Wermuth lagde ud med, at slå fast, at Continuous Integration ikke er et færdigt værktøj, der kan købes og tages i brug. Derimod er der tale om en metode, som man skal tage en beslutning om at bruge. Continuous Integration er en effektiv måde at udvikle software på. De fleste der arbejder med softwareudvikling vil være enige i, at udvikling i et projekt kommer af at man undervejs gør sig en masse, mere eller mindre smertefulde, erfaringer. Der hvor det ofte går galt, er når kode skal integreres. Derfor er det smart at effektivisere integrationen. Desuden giver udviklingsarbejdet størst værdi når koden er i produktion. Dette formulerer forfatter, foredragsholder og “guru” inden for softwareudvikling, Martin Fowler således:
“It’s hard enough for software developers to write code that works on their machine. But even when that’s done, there’s a long journey from there to software that’s producing value – since software only produces value when it’s in produktion.”
Hvorfor Continuous Integration?
Der er adskillige gode grunde til at Continuous Integration er værd at kigge nærmere på – særligt for udviklingsteams, der arbejder agilt. Ræsonnementet bag de agile metoder er i høj grad at vi er interesserede i en hurtigere udviklingsprocess hvor fejl og mangler bliver opdaget og rettet løbende frem for at teamet står med en uoverskuelig mængde issues som alle skal løses på én gang.
Præcis det samme gør sig gældende for konceptet Continuous Integration på kode-niveau. Det gælder om at integrere sin kode med korte mellemrum og helst dagligt. Jo mindre kode der commites til projektets main branch desto færre integrationsfejl vil man støde på, og dermed vil man hurtigere kunne gå i gang med at være produktiv igen.
Det er dog ikke kun til gavn for selve produktiviteten. Continuous Integration fungerer i allerhøjeste grad også som et ekstra lag af kvalitetssikring for produktet. Størstedelen af Continuous Integration-processerne er automatiserede. Når udvikleren har integreret sin kode sker build, deployment, unit tests og integration tests automatisk og udviklingsteamet får således hele tiden feedback på om alt er som det skal være.
Men lovprisninger af Continuous Integration findes der oceaner af, og alligevel svarer mere end halvdelen af de adspurgte i en undersøgelse foretaget af Dimension Data fra 2017, at de højst deployer én gang om ugen.
Er det kompliceret at komme i gang med Continuous Integration?
Jesper Wermuth lagde i sin introduktion ikke skjul på, at Continuous Integration kan synes kompliceret at komme i gang med. Det er ikke nødvendigvis dyrt, men det kommer an på hvor “godt” et setup man ønsker. Det er svært, at få det fulde udbytte ud af Continuous Integration, hvis ikke man allierer sig med resurser, der kender til Continuous Integration og har erfaring med at implementere det.
De værktøjer, man bruger i forbindelse med Continuous Integration, har udviklet sig meget, og gør det stadig. Det kræver derfor en del at holde sig opdateret på værktøjerne. Det gør det svært at komme i gang, hvis ikke man er opmærksom på hvilke udfordringer, der kan opstå undervejs.
Det tekniske aspekt er ikke det eneste der kan give udfordringer, når en organisation implementerer Continuous Integration. Arbejder en udvikler alene, er det simpelt at kode og deploye. Man har kun sig selv, at skyde skylden på når noget går galt og problematikkerne er begrænsede. Man koder, tester, fixer og deployer.
I teams er det mere komplekst. Der kodes parallelt og koden skal flettes sammen i en fælles kode, hvorefter det hele skal fordeles, så teamet kan arbejde videre. Processen stiller krav om koordination.
Teammedlemmerne er afhængige af hinanden. Kæden er ikke stærkere end det svageste led. Det er nødvendig at dele viden. En af de fejl, som desværre ses ofte er når viden monopoliseres. Når én medarbejder sidder med viden om en del af projektet, forringer det muligheden for at arbejde parallelt og effektivt.
Alligevel bør man overveje at bruge de ressourcer der skal til for at få implementeret Continuous Integration samt Continuous Delivery og Continuous Deployment i organisationen. Flere undersøgelser viser, at der er tid og penge at spare ved det.
Continuous integration er fundamentet for continuous delivery og continuous deployment.
Hvordan gør man så?
Der er guidelines til hvordan man skal agere som team, for at få bedst muligt udbytte af Continuous Integration. Som nævnt er Continuous Integration et supplement til agil udvikling og de to koncepter understøtter hinanden. Det anbefales, at holde daglige stand-up møder, som vi kender det fra SCRUM, hvor alle i teamet fortæller hvad de laver.
Kommunikationen er essentiel. Det gælder især, når informationer ikke udveksles ansigt til ansigt. Eksempelvis anbefales det, at alle skriver meningsfyldte commit messages på omkring 60-80 karakterer. Er de kortere, kan det være svært at forstå, hvilke ændringer der er blevet lavet. Er de for lange, bliver det hurtigt uoverskueligt, at lede efter en bestemt version i en lang liste af commit beskeder. Der skal ligeledes være styr på versionsstyring. Det er ikke effektivt at bruge tid på at finde rundt i versioner af kode.
Alle bør committe alt, hvad der skal bruges til at bygge koden. Der skal committes hver dag og alt hvad der committes til base line skal bygges.
Jesper Wermuth lagde i sin introduktion vægt på, hvor vigtig automatisering er indenfor Continuous Integration. Både build, tests og deployment bør automatiseres. Helt konkret anbefalede Jesper Wermuth, at buildet startes fra command line frem for i en IDE, og at et build tool benyttes. Af eksempler kan nævnes Gradle, Maven, Make etc. En af fordelene er, at byggeserverne laver build pipelines, hvilket er en metode til parallelisering tests på. Skal en funktionalitet eksempelvis testes i forskellige browsere, kan det at ske parallelt frem for at der testes serielt browser for browser.
Et build må ikke tage for lang tid
Det anbefales, at man sørger for, at et build ikke tager lang tid. Optimalt må det ikke tage mere end 90 sekunder. Jo længere et build tager, desto større risiko for at der bliver set igennem fingre med fejl. Hvis der først er én fejl, begynder andre på teamet også at acceptere fejl. På den måde accepteres flere fejl. Det er spiralen uden ende.
Som afrunding på introduktionen i Continuous Integration, kom Jesper Wermuth ind på, hvor vigtigt det er at teste software. Det er vitalt for at Continuous Integration kan fungere, at man har en test suite af høj kvalitet.
Det kræver flere ressourcer, at rette en fejl når koden er ude, frem for tidligt i processen. Når koden overdrages til en anden udvikler og fejler i test, skal fejlen findes og rettes med det samme. Det er en fejl at negligere tests – Testen er lige så vigtige som resten af koden.
Selv er Jesper Wermuth varm fortaler for Test Driven Development (TDD), hvor man skriver sine tests før selve koden. “Man får et bedre liv på den måde” pointerede Jesper Wermuth. Egnede værktøjer hertil er blandt andre Cucumber og Spock.
Til slut spurgte Jesper Wermuth ind til, om der var andre problemstillinger deltagerne gerne vil høre mere om.
En deltager spurgte om Lund&Bendsen har erfaring med at implementere Continuous Integration i store organisationer med komplicerede IT-strukturer. Det kunne Jesper Wermuth svare “Ja” til, og uddybede, “Det kan man godt, men det tager tid.
Man skal omstille sin softwareudvikling til at fungere på den måde. Man tager det i steps, hvis der er tale om en stor virksomhed. Afdelingerne forbereder sig på omstillingen og kommer med når de er klar. Jeg har dog aldrig har oplevet at nogen har fortrudt, når Continuous Integration-systemerne er oppe og køre”.
