Har du jobbat med andra programmerare mot samma källkodsbas någon gång? Kanske CVS, SVN, bzr eller git? Då vet du att det ofta känns bättre att upload:a än att download:a.
Upload kallas lite olika i olika system; commit i CVS/SVN, och push i bzr. git kan jag inte så där vet jag inte vad det kallas.
Download heter update i CVS/SVN, och har lite olika namn beroende på vad exakt man ska göra i bzr: merge, update eller pull.
Kodbas = djungel?
I vilket fall — den teknik jag vill prata om idag kallas alltså ”kontinuerlig integration” vilket känns lite sisådär namnmässigt. Det låter mera som det är en matematisk definition eller teorem snarare än en mjukvaruutvecklingsteknik.
Så vad går CI ut på? Kort kan man säga att CI går ut på att kontinuerligt bygga trunken/mainline/gemensamma källkodsbasen på en separat ”byggmaskin”, och signalera programmerarna så fort något går fel. T.ex. via mail eller en tray-ikon som blir röd istället för grön.
Så enkel är principen bakom CI!
Du kanske frågar dig ”Vad gör detta för nytta då?”. Grejen är den att om du kan se någonstans på skärmen att trunk är ”healthy” så är det inte så mycket att oroa sig för innan du gör en uppdatering av din kodbas. Du litar helt enkelt mera på den gemensamma kodbasen.
CI = Hjärtmonitor för trunk
Ett CI-system kan alltså betraktas som en ”hjärtmonitor” för den gemensamma koden!
Omvänt, om det finns ett tydligt signalsystem till programmerarna, hur den gemensamma basen ”mår”, så är man lite mera försiktig vid checkin/commit. Och om man råkar göra fel, får man reda på det inom några minuter, istället för när en halvirriterad kollega gnäller på att man glömt Add:a någon ny fil.
I praktiken kan en CI vara allt från ett schemalagt litet byggscript på din egen utvecklingsdator, till en separat server med massa avancerade verktyg.
På jobbet har jag en gammal ”skruttdator” för CI. Det känns bra att en gammal ”obrukbar” dator kommer till användning! Jag har gjort det lätt för mig och byggt några .bat-filer (ja, jag jobbar i Windows på jobbet på gott och ont) som i tur och ordning:
- uppdaterar den lokala källkoden på servern så den får senaste version av gemensamma kodbasen
- bygger hela lokala Solution i Release-config
- kollar om det gick bra eller ej. Om det gick kass, skapas en liten ”flaggfil” (typ ERROR) på nätverket.
Detta ”CI-script” körs c:a var femte minut.
Min lilla "Byggmonitor"
På min egen jobbdator har jag en Tray-applikation byggd i C# som kontrollerar den här flaggfilen en gång i minuten. Sedan visar den antingen en grön eller en röd ikon beroende på om flaggfilen finns eller ej. Jag kallar applikationen ”Byggmonitor”.
Det är väldigt enkelt och simplistiskt – men det är så jag gillar saker!
För övrigt har jag utökat flaggfilen med att inkludera Error-rader från kompileringen på CI-servern, så det blir lite mera info om hur bygget gick. Den innehåller också information om när sista bygget skedde. På så sätt vet jag om CI-scriptet plötsligt slutat fungera.
Sedan kan man ju utöka CI-scriptet så det kör alla enhetstester/integrationstester på servern också. Men bara kompileringssteget är det allra mest givande i min erfarenhet. Utvecklare kör ju enhetstester/integrationstester så ofta på sina egna burkar.
Sammanfattningsvis kanske man kan säga att med ett CI-system ökar utvecklarnas förtroende för den gemensamma källkoden. Därmed uppdaterar alla oftare och committar oftare.
Taggar: programmering, ci, continous integration, kontinuerligt bygge, bzr, git, svn, cvs
Besök bloggosfären!
OlofB[eta] 