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.