Johan babblar på.

Försäkra dig om att dina automatiska, dagliga och kontinuerliga, byggen verkligen fungerar.

Det är precis som att kontrollera att dina backuprutiner fungerar. Du vill inte komma på att någon av dem slutat fungera när du verkligen behöver dem.

I helgen flyttades vår Team Foundation Server och allting såg ut att fungera som det skulle på måndagsmorgonen. Det var inga problem alls att ansluta till den nya servern och Cruise Controls lilla ikon sken betryggande grönt. Jag hade dock en lite oroande känsla av att något inte stod rätt till…..

…och se’n kom det; Konfigurationsfilen till Cruise Control var inte uppdaterad så den kontrollerade och byggde källkoden på den gamla servern.

Trasiga byggen suger och det borde vara en kollektiv uppoffring att hålla systemet i ett byggbart skick, men någon måste vara ansvarig för automatiseringen. Någon som kontrollerar att bygget fungerar.

Jag har ganska ofta hamnat i diskussioner om hur vi ska lösa ett spcifikt problem och vad användaren egentligen vill lösa med sin ändringsbegäran. Det är inte ovanligt att det hade gått fortare att implemenera alla möjliga lösningar och låta användaren välja vilken som är rätt än att diskutera kring det.

Om vi har en fungerande kontinuerlig integration som genererar något som går att leverera skulle vi i många av dessa fall kunna implementera flera olika lösningar och låta kunden avgöra vilken lösning som ska användas.

Jag har hör talas om organisationer som tagit kontinuerlig integration så långt att de skapar Virtual PC filer med systemet färdigistallerat som en del av det dagliga bygget. Det betyder att även om du har serverprogram som en del av produkten kan du göra snabba leveranser.

Jag har ofta hamnat i situationer där säljare lovat funktionalitet till existerande och presumtiva kunder. Funktionalitet som inte funnits och som ofta krävt omfattande övertidsarbete och fulhackande för att få klar. När utvecklare, mer eller mindre högljutt, protesterar mot detta förfarande brukar det antingen skrattas bort eller förklaras med vi inte förstår säljprocessen.

Väldigt ofta hinner man inte heller testa dessa framstressade funktioner vilket hur som helst leder till att mottagaren blir missnöjd med leveransen.

Förutsatt att man tagit fasta på mitt tidigare råd att ha installerbara dagliga byggen föreslår jag att man i stället levererar det som finns och uppdaterar med ny funktionalitet varefter den blir färdig. Med kortare leveransintervall får alla inblandade en större framgångskänsla. Detta fungerar förmodligen inte för alla typer av system, men väldigt många gånger är det inte kritiskt om man introducerar ett fel som en regressionstest skulle ha hittat. Risken är ganska stor att ett testförfarande som bara utförs ett par gånger om året i alla fall missar mer än ett som utförs varje dag. Dessutom ‘vet’ mottagaren att den typen av fel kan åtgärdas ganska snabbt eftersom man levererar ofta.

Jag tycker inte att man ska behöva vara rädd för att leverera ofta. Ett sätt att dämpa den rädslan är att ha en väl fungerande automattestnings- och byggmiljö.

Skaffa 2GB säker datalagring online!



När man gör dagliga byggen, vilket jag tycker är ett av baskraven för kvalitativ systemutveckling, bör man se till att bygget är så komplett och lätthittat att test och sälj själva kan installera den version de vill ha för stunden.

Det är en vedertagen sanning att det blir dyrare och dyrare att rätta fel ju längre man väntar. Om test kan verifiera en felrättning dagen efter den checkats in i källkodshanteraren i stället för att vänta till nästa sanktionerade release minskas både ledtider och kostnader.

För att detta ska fungera krävs att hela organisationen jobbar för att det dagliga bygget ska vara fullständigt. Det håller inte om någon sitter i hemlighet och checkar in obrukbar kod. Om man utvecklar för en specifik kund, som förväntar sig att se ständiga uppdateringar, blir det extra illa om någon i det dolda checkar in dålig kod. Det är ett problem som man inte kommer runt med enhetstester eftersom deras resultat går att manipulera.

Det krävs att alla jobbar för att det dagliga bygget alltid ska vara färdigt för release.

Nightly builds are almost useless if there is no collective responsibility to keep the code in a buildable state.

Why should I even bother to make sure my code builds before checking in, when the build has been broken for a week and no one, who can/should do anything about it, cares?

Is it the responsibility of the ones who do care to be a PITA, or should we take it upon our selfs to fix all error just because we care?