Introduktion Til Continuous Integration

Hvad er continuous integration?

Continuous Integration er en samling af processer, der tilsammen udgør en væsentlig del af kvalitetskontrollen i moderne softwareudvikling. Det er små, men ofte udførte, automatiske handlinger som vi tilsammen kalder "et build". CI bliver dermed dels en konstant overvågning af systemets helbredstilstand og dels en fabrik for et system, der til stadighed er testet og integreret. Klart til brug.

En konsekvens ved at bruge Continuous Integration er, at vi får et hurtigt svar på, om vores software har opnået en kvalitet, der kan tåle eksekvering. Vi søger at opnå en højere kvalitet ved at fejle så tidligt som muligt, så vi kan rette fejlene.

 Det bedste er aktivt at søge, at få systemet til at fejle! Det bruger vi automatiske unit tests til.

Anvender man ikke unit tests giver Continuous Integration alligevel værdi - omend i mindre omfang - idet det vi stadig får en validering af, at systemet kan bygges med det der nu engang er checket ind samt en stor del af de øvrige fordele nænvt senere i indlægget.

 Resten af indlægget tager udgangspunkt i, at man bruger unit tests.

 Vi har 3 tilstande vi skal forstå i Continuous Integration: Gul, rød og grøn. Mens systemet bygges er det i den gule tilstand. Hvis vores build gik godt er vi i den grønne tilstand. I alle andre tilfælde er vi i den røde tilstand. Den røde tilstand skal der gøres noget ved med det samme fordi det hindrer videre fremdrift, den konstante overvågning af systemets helbredstilstand, sikkerhed for udviklingsteamet og dermed sikring af investeringen i software.

Det er værd at pointere, at et samlet og færdigbygget system aldrig kan være i den gule tilstand. Det er enten rødt eller grønt.

 Vi ønsker at automatisere denne proces så meget som muligt.

 Til den ende bruger man en såkaldt Continuous Integration server - eller en byggeserver på dansk. Continuous Integration serveren er software, der reagerer på ændringer i et versionskontrolsystem (eller på udvalgte tidspunkter) og får ansvaret med at udføre f.eks. disse handlinger på vores vegne:

  

Lidt mere fingranuleret kan det se sådan ud:

  • Check ud / Get fra versionskontrolsystem
  • Byg systemet
  • Beregn metrics
  • Etablér testdata
  • Kør automatiske test
  • Producere rapporter
  • Byg deployment pakke(r)
  • Deploy til diverse miljøer
  • Publicér resultatet af bygget

Der er naturligvis rige muligheder for at definere andre opgaver, som Continuous Integration serveren kan tage sig af; men man bør udelukkende lade den varetage opgaver, som naturligt tilhører en buildproces.

 Anbefalinger til opsætning og brug af Continuous Integration builds

 I langt de fleste tilfælde giver det mest mening, at man definerer et antal Continuous Integration builds, der passer sammen med kategorisering af de unit tests man skriver til trykprøvning af systemet, et eller flere integration builds samt et eller flere deployment builds.

Følgende eller lignende kategorier til test og builds kan fungere udmærket:

  • Unit: Kategorien dækker de dele af systemet, som ikke har afhængigheder til subsystemer (f.eks. databaser m.v.). Et Unit test build går hurtigt - sekunder eller ganske få minutter. Ikke længere.
  • Component: Kategorien dækker de dele af systemet, som kan dækkes i en kompileringsenhed (f.eks. et assembly) og som ikke har afhængigheder til andre komponenter. Hvis øvrige komponenter ikke kan afkobles fuldstændigt må disse dækkes via type mocking. Et Component build går hurtigt. Ikke længere end få minutter.
  • System: Kategorien dækker de dele af systemet, som har afhængigheder til andre subsystemer, herunder databaser, hardware o.l. Et System build bør gå hurtigt; men kan i visse tilfælde tage længere tid end ønskeligt idet systemet testes i sin helhed. Det er ønskeligt, at et komplet System build holdes under 10 minutter af hensyn til at få besvaret spørgsmålet - er vi i "grøn" eller i "rød"?
  • Deployment: Kategorien dækker deployment scenarier, hvor et komplet og testet System build f.eks. kan deployes til test, pre-production, production eller lignende miljøer. Et Deployment build kan gå relativt langsomt. Det afhænger af om man beslutter sig for at deploye et System build eller om man beslutter sig for at bygge igen. Det afhænger naturligvis også af størrelsen på buildet, deployment target herunder platform, netværk osv.

Er man udfordret med lange byggetider er det måske på tide med en refaktorering, hvorved der kan opstå nye builds.

 Bruger man f.eks. NUnit og .NET kan man bruge Category attributten til at markere tests med og disse kan konfigureres op / filtreres i Continuous Integration serveren, så kun de ønskede tests udføres i det pågældende build.

 De enkelte builds kan trigges med dependencies - dvs. i et hiearki. Man kan naturligvis også sætte f.eks. daily/nightly builds op, som afvikles på forudbestemte tidspunkter.

 Det kan anbefales, at man checker ind meget ofte. Helst flere gange om dagen, så man hele tiden er synkroniseret med det øvrige udviklerteam og så man hele tiden har et svar på om systemet forventeligt er i en sund tilstand.

Hvilke Continuous Integration servere findes der?

 Mange! Her vil jeg blot nævne nogle af de mere populære i den rækkefølge, som vi bedst kan lide dem.

  • TeamCity (TC): Det er et rigtig stærkt værktøj, som man kan få lov til at bruge gratis, hvis man er under en vis størrelse. Det er JetBrains der udvikler TC.
  • Cruise Control.NET (CC): CC er open source og dermed gratis og udmærker sig desuden ved at være utroligt meget brugt og dermed er der masser af hjælp af hente på nettet. Til gengæld er CC markant sværere at sætte op end f.eks. TeamCity. Det er ThoughtWorks der udvikler og vedligeholder CC.
  • GO: GO udvikles også af ThoughtWorks og er deres kommercielle bud på en Continuous Integration server. GO findes dog også en nedskaleret Community Edition.
  • Bamboo: Bamboo udvikles af Atlassian som bl.a. også udvikler JIRA og mange andre ALM produkter.
  • Hudson

Alle Continuous Integration servere kan levere udtømmende rapporter om hvordan buildet gik. Det kan vi tage i et senere indlæg.

Referencer

Add comment

Loading