CruiseControl.NET az alapoktól

Az elmúlt időszakban sikerült elég mélyen beleásnom magam a CrusieControl.NET rejtelmeibe, ezért úgy gondoltam, hogy itt az ideje ezt megosztani másokkal is, magyar nyelven!

Mi is a CrusoeControl.NET (továbbiakban csak CC.NET)?

Ahhoz, hogy a szoftverfejlesztés folyamatos és megfelelő minőségben történjen, szükséges egy olyan belső szabályozási rendszer, amely mind a fejlesztést-, a fordítást-, tesztelést-, és publikálást is keretek közé foglalja.

Több ajánlás is létezik, ezek közül az egyik (és talán kevésbé ismert) az CI, azaz  Continous Integration magyarra lefordítva Automatizált Folyamatos Integráció.

Lényegében egy ajánlás arra vonatkozóan, hogy a fejlesztési területeket (gyakran több fejlesztői csoport közös munkája egy rendszer) összefogva automatizált műveletekre támaszkodva segítse az építés (build), tesztelés (testing), és kiajánlás (deploy) folyamatát.

A CCl.NET a CI folyamatokat automatizáló szoftver. Azaz a teljes folyamatos integrációt automatizáló keretrendszer.  A CC.NET egy keretrendszert ad a build műveleteket felparaméterező kezébe, amellyel le tudja képezni a teljes folyamatot a saját szájíze szerint. Azon kívül, hogy keretrendszert ad, lehetőség van saját kiegészítők készítésére is, ha a CC.NET -ben nincs megfelelő eszköz rá (erről a későbbiekben még fogok írni!).

Egy tipikus példával szeretném szemléltetni ezt a folyamatot.

FejlesztőCég Kft két vezető fejlesztővel, 1 ügyfélszolgálati vezetővel, 8 fejlesztővel, 1 adatbázis szakértővel, 2 tesztelővel, 4 ügyfélszolgálatossal készíti az ÜgyviteliSzoftver 3.0 -t.

Az ÜgyviteliSzoftver 3.0 egy alkalmazásból, és a hozzá tartozó ügyviteli modulokból épül fel. Az alkalmazást 2 fejlesztő készíti, a pénzügyi modulokat 4 fejlesztő, míg az egyéb modulokat 2 programozó fejleszti. Az alkalmazást- és egyéb modulokat az egyik vezető fejlesztő, míg a pénzügyi modulokat és az adatbázis szakértőt a másik vezető fejlesztő felügyeli. A tesztelők és ügyfélszolgálatosok munkáját az ügyfélszolgálati vezető látja el.

Céljuk az, hogy napi build -ek, illetve release build -ek készüljenek egy – egy nagyobb fejlesztés / javítást követően.

A cc.NET ebben nyújt igen nagy segítséget.

A folyamatoknak összehangoltnak kell lenniük, és egymásra épülőknek, hiszen egy hibás modul miatt a napi build elromolhat, és a tesztelésre se kerülhet sor emiatt.

A build -re épül az automatizált tesztelés, erre épül a kipublikálás.

Ahhoz, hogy ne legyen Integrációs Pokol, minden build egy központi forrástárolóból, példánkban a Microsoft TFS -ben (Team Foundation Server) tárolódik. A fejlesztés programnyelve a Visual Basic .NET, Microsoft SQL Server -t használnak, és a deploy Microsoft Installer -el készül.

A FejlesztőCég Kft naponta, kétszer, 12 és 16 órakor szeretne napi build -et készíteni, továbbá hetente egyszer hétfőn release build -et.

A folyamat a következő lépésekből áll:

• Aktuális forráskódok letöltése
• Aktuális DB verzió letöltése
• Aktuális DB verzióra „húzása”
• A fő alkalmazás lefordítása
• A pénzügyi modulok lefordítása
• A kiegészítő modulok lefordítása
• A fő alkalmazás automatizált tesztelésének indítása
• A modulok automatizált tesztelésének indítása
• Publikálási folyamat indítása

A folyamat bárhol elakad, arról a megfelelő csoportnak vagy embernek tudnia kell. 
A CC.NET -ben lehetőség van csoportok és felhasználók definiálására, e-mail címek beállítására, továbbá a csoportokhoz és felhasználókhoz jogosultságok beállítására.

Példánkban a vezető fejlesztő lesz az egész rendszer adminisztrátora. Létre hoz hét csoportot:

1. Alkalmazás készítők csoportja
2. Pénzügyi modul készítők csoportja
3. Kiegészítő modulok készítőinek a csoportja
4. DB csoport
5. Tesztelő csoport
6. Adminisztrátorok csoportja
7. Menedzserek csoport

Vezető fejlesztőnket a teljes folyamat végeredménye érdekli, ezért a vezető fejlesztők, illetve az ügyfélszolgálati vezető a Menedzser csoportba kerül. A többi csoport tagjai értelemszerűen a megfelelő fejlesztők, adatbázis szakember és tesztelők. Az Adminisztrátor csoportba a két vezető fejlesztő kerül, ennek a csoportnak van joga az egész folyamatot menedzselni.

A megfelelően beállított jogosultságok után be kell konfigurálni a TFS hozzáférést, a megfelelő könyvtárakat (ahova a build készül), továbbá a DB elérhetőségeket.

Ha ezzel is elkészült, jön a folyamat legfontosabb része, a megfelelő dependencia felállítása.

Ezt a következők szerint definiálta az adminisztrátor:

• Az adatbázis változások átvezetése (hiba esetén a DB csoportnak levél, és a folyamat leállítása)
• Fő alkalmazás fordítása (hiba esetén levél az Alkalmazás készítők csoportnak, és a folyamat leállítása)
• Pénzügyi modulok fordítása (hiba esetén levél az Pénzügyi modul készítők csoportnak, és a folyamat leállítása)
• Egyéb modulok fordítása (hiba esetén levél az Kiegészítő modulok készítők csoportnak, és a folyamat leállítása)
• Automatikus tesztek futtatása (hiba esetén levél a Tesztelő csoportnak, továbbá levél a hibás eredménnyel visszatérő modul vagy alkalmazást fejlesztő csoportnak)
• Publikálás (hiba esetén levél a Menedzsereknek, továbbá a publikálási script -ért felelős csoportnak)
• Sikeres publikálás esetén levél a Menedzser és a Tesztelő csoportnak

A napi build -ek így naponta kétszer készülnek, a megfelelő embereket értesítve.

De mi van a heti egyszeri release build -el?

Fontos, hogy a hétfői build működőképes és tesztelt legyen. Ezért a hétfői heti release folyamat a péntek 16 órai tesztelt build folyamathoz kötött. Azaz, ha pénteken 16 órakor nem készült működő és tesztelt verzió, akkor a hétfői release build se készül el!

A CC.NET -ben lehetőség van arra is, hogy kézzel indítsunk el folyamatokat, azaz ha a pénteki verzió nem működött, és emiatt nem indult el a hétfői release build, de hétfőn a 12 órás build tökéletesen lefutott, akkor az adminsiztrátornak lehetősége van kierőszakolni (force) egy build -et.

 

Ebben a rövid bevezetőben még nem tértem ki sok más, és izgalmas funkciójára a CC.NET -nek, de ami késik, nem múlik!