Dette indlæg er et afsnit i serien om Continuous Integration.

Nu er der jo ikke meget sjov ved bare at check koden ud, så lad os få bygget noget. Vi starter med at tilføje en task:

<tasks>
  <nant>
    <baseDirectory>d:\dev\framework</baseDirectory>
    <executable>d:\dev\tools\nant\nant.exe</executable>
    <buildFile>framework.build</buildFile>
    <targetList>
      <target>clean</target>
      <target>compile-tests</target>
    </targetList>
  </nant>
</tasks> 

Task elementer kan indeholde mange forskellige opgaver hvor vi her har valgt at køre et NAnt script. Man kunne vælge at bruge MSBuild til at bygge VS solutions med, men jeg flytter nogle ektra ting ned i build scriptet som også kan køres på udvikler maskiner. Mit NAnt script kalder så MSBuild scripts, så du har egentlig tre niveauer for hvor du skal bygge:
CC, NAnt, MSBuild (Tilføj selv flere efter behov). Hvilket niveau du vælger afhænger af dine ønsker, men jeg fortrækker at man har mulighed for at kontrollere både build og unit-tests inden man checker kode ind i source kontrol systemet.

Dette script bygger to target: Et clean target (så vi slipper af med gammelt bras) og et compile target som bygger unit test, men som afhænger af at frameworket et bygget. Tilføj selv flere targets efter behov.

Hvis du har installere på en frisk maskine uden Visual Studio, så løber du nok ind i problemer med NAnt. Problemer udmønter sig i brok over at installDir for net-2.0 ikke er angivet og det er selvom du tvinger den til at bruge net-3.5. For at løse det finder du din NAnt.exe.config fil og søger efter readregistry elementer. Attributen sdkInstallRoot skal rettes. I mit tilfælde (jeg bruger Windows SDK 6.1) til: SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1\WinSDKNetFxTools\InstallationFolder. Det skal lige gøres et par steder, så kører det. Dette kan dog være løst i en nye version af NAnt når du læser dette. Jeg har taget udgangspunkt i TreeSurgeon som giver dig både et buildscript og de tilhørende filer.

Når vores projekter er bygget kan vi kopiere bygget til vores filserver med denne lille build publisher:

<buildpublisher>
  <sourceDir>d:\dev\framework\build</sourceDir>
  <publishDir>\\fileserver\framework</publishDir>
</buildpublisher>

Så er der altid adgang til det nyeste build.

Når nu det hele kører så mangler vi bare den automatiske del. Til det formål har CC en række triggers hvoraf ForceBuildTrigger er default. Det mest oplagte for CI er at indsætte en IntervalTrigger i triggers blokken:

<triggers>
  <intervalTrigger name="Continuous" seconds="60" />
</triggers> 

Med denne trigger vil CC checke subversion hvert minut. Hvis der er sket ændringer vil den sætte gang i et nyt build. Et natligt rebuild kan tilføjes med en ScheduleTrigger

<scheduleTrigger time="23:30" buildCondition="ForceBuild" name="Scheduled" /> 

Bemærk at buildCondition er sat til ForceBuild mod default at være IfModificationExists. Dette kan også bruges for intervalTrigger hvis man skulle få brug for det. Der er mange muligheder for at tilpasse triggers, så f.eks. der ikke bygges på bestemte tidspunkter med FilterTrigger eller at ScheduleTrigger kun bygger på hverdage. Se mere under http://confluence.public.thoughtworks.org/display/CCNET/Trigger+Blocks

Nu er det bare at checke noget nyt kode ind og vente på at de dit byg (hvis du altså ikke vil vente til kl 23.30).

Dette indlæg er et afsnit i serien om Continuous Integration.

For at få vores Continuous Integration til at spille skal vi bruge et source kontrol system. Hvis du allerede har et source control system kan du springe de næste to afsnit over.

Som source control system har jeg valgt subversion og til serveren er valgt VisualSVN Server. VisualSVN laver også et plugin til Visual Studio, men modsat serveren, så skal du betale for det (i skrivende stund er prisen $49). Alternativt kan du bruge AnhkSVN, eller hvis du vil klare ærterne udenfor VS, så TortoiseSVN. Bemærk dog at der er forskel på SVN 1.5 og 1.6. Jeg løb ind i nogle uløselige "tree conflicts", så pas på med versionerne - Specielt hvis du får flyttet eller kopieret SVN folderen i dit checkout. Dette kan dog være rettet når du læser dette.

Efer at ha' installeret Visual SVN Server vælger du 'VisualSVN Server Manager' fra startmenuen. Højreklik på roden i træstruktion, vælg options og vælge hvor du vil ha' dit repository til at ligge. Her kan du også vælge mellem Windows og subversion authentication og hvordan du vil tilgå dit repository. Opret dit repository (gerne med den anbefalede trunk/brances/tags struktur) og evt. brugere. Der er en kort beskrivelse (om end noget længere end min) af opsætningen proceduren på VisualSVNs hjemmeside. Lav et checkout på din udvikler maskine, fyld nogle filer i og commit ændringerne.

Nu skal vi så igang med CC. Programmet kører som default ikke efter det er blevet installeret. Det skal først konfigureres og det er meget nemmere at bruge CC console programmet som der ligger et link til på dit skrivebord. Du kan sagtens starte consolen og se programmet køre. Når du opdaterer konfigurationen indlæses den nye fil automatisk. Efter at konfigurationen er kommet på plads installeres services ved at køre installutil på ccservice.exe i server folderen.

Indtil videre starter vi blot CC ved at bruge linket på skrivebordet og finder ccnet.config i server folderen (der er også en ccnet.exe.config som kan bruges til at styre f.eks. logging). Det er en simple xml fil som indeholder alle de projekter din build server skal bygge. Lad os start med et enkelt projekt og lad os gi' vores projekt et navn:

<cruisecontrol>
  <project>
    <name>Framework</name>
    <workingDirectory>d:\dev\framework</workingDirectory>
    <artifactDirectory>d:\dev\framework\artifacts</artifactDirectory>
  </project>
</cruisecontrol>

Da jeg var igang valgte jeg også lige at fortælle hvor jeg ville ha' projektet liggende, men ellers sker der ikke så meget der er værd at se. Appropos se, så kan du holde øje med projektet via dashboardet på http://bs/ccnet. Den kan melde nogle fejl, men de forsvinder efterhånden som du får konfigureret og bygget projektet. Dashboardet har også et link til CCTray som du kan installere på din udvikler maskiner og som navnet antyder viser CC status som tray icon.

Hvis du vil ha’ flere projekter tilføjer du bare yderligere projekt elementer i konfigurationsfilen. Men først må det være tid til at checke noget kode ud fra vores Subversion repository ved at tilføje et sourcecontrol element under project noden:

<sourcecontrol type="svn">
  <trunkUrl>http://bs:8080/svn/framework/trunk</trunkUrl>
  <executable>d:\Program Files\VisualSVN Server\bin\svn.exe</executable>
  <workingDirectory>d:\dev\framework</workingDirectory>
</sourcecontrol>

TrunkUrl og executable afhænger af din Subversion installation. Jeg har valgt at køre på samme server og bruge subversion authentication, men du kan gøre andre valgt. Det er også muligt at angive username og password elementer. Det er også muligt at vælge andre source kontrol systemer, men så kan der være andre detaljer som skal udfyldes.

Hvis du går ind i dashboarded og ser dit projekt kan du vælge "Force Build", hvorefter du skulle kunne se dit checkout i d:\dev\framework folderen hvis builded afsluttede succesfuldt. Build rapport giver også en oversigt over hvilke filer der er checket ind siden sidste build og hvilke beskeder der er attachet til checkins. Så ikke noget med at skrive junk beskeder når du checker ind. Hvis buildet fejlede af den ene eller anden grund (compilefejl, unit test fejl, etc.) så vi man også her kunne se hvem synderen er.

I næste indlæg skal vi se hvordan vores build rent faktisk får bygget noget.

Dette er starten på en lille artikelserie om Continuous Integration med Cruise Control .Net (herefter blot CC). Continuous Integration (herefter blot CI) stammer egentlig fra Extreme Programming, men bruges også af folk som ikke kender til XP. Der er mest tale om en proces som giver en række fordele hvis man bider ind i konceptet. Med denne artikel serie vil vi bruge en række værktøjer til at få

• Vores .net projekter under et source kontrol system
• Bygget koden automatisk når vi checker ændringer ind
• Kørt vores unit-tests automatisk
• Nemt overblik over status på vores builds

Målet er at man vælger at checke ændringer ind tidligt og ofte, fordi man hurtigt kan se effekten på hele projektet. Det kan betale sig lige at se Martin Fowler's Artikel om Continuous Integration hvis man ikke har kendskab til emnet. Ikke noget med at ha' flere moduler liggende på en udvikler computer som ta' nogle dage at integrere i resten af projektet.

Det kan lyde af meget for en hobby programmør, men selvom du (endnu) ikke skal arbejde sammen med andre end dig selv, så er dele af processen stadig en fordel. Versions styring bør være nemt nok til at alle kan bruge det og man bør alligevel få sig et build script så snart projektet vokser til flere solutions. Brug CI som inspiration i din process og ta' de ting med dig du kan bruge.

Til denne artikelserie skal du bruge:

• En build server maskine med IIS
• Evt. Windows SDK hvis det er en frisk maskine
• VisualSVN Server
• Cruise Control .Net
• NAnt
• NUnit

Jeg har installeret CC på min WHS og det kræver derfor jeg installerer et Windows SDK. Hvis du bruger en maskine som har installeret Visual Studio, så har du sikkert allerede det SDK du skal bruge. Hvis ikke, kan du løbe ind i nogle problemer lige som mig, men dem løser vi. Hvis du bruger din WHS så husk at installere på D drevet.

Du kan lige så godt komme igang med at downloade programmerne og få dem installeret på din build server (lad os kalde den BS til ære for B.S.) med det samme. Jeg vil ikke gå videre i dybden med hvordan man bruger SVN, NAnt eller NUnit. Der findes mange spændende tutorials på nettet om de emner, du kan læse mens jeg arbejder på flere artikler i serien.

Listen over planlagte artikler ser således ud:

• Versions kontrol med Subversion
• Automatiske builds
• Unit tests

Når der kommer nye indlæg vil jeg linke til dem fra denne side.