Pidev integratsioon
16.11.2007 | MarekLäbi aegade on pisike integratsioonikurat kiusanud arendajaid. Tänu talle venivad projektid ja paljud vead tulevad alles süsteemi kasutuse juures välja. Peale selle on arendajate jaoks integreerimine kui põrgu katlas istumine – ei tea kunagi, millal vesi keema läheb. Väledates metoodikates (agile methodology) on põrgule vasturohi olemas – pidev integratsioon. Seda praktikat tasub ka kasutada kõige jäigemates protsessides, sest kasu on küllaltki suur. Enne kasu saamist tuleks vaadata, mis see täpsemalt on.
Pidev integratsioon on protsess, mis käivitub pärast failide lisamist koodihoidlasse. Protsess hõlmab esmaselt versiooni numbri uuendamist, süsteemi kompileerimist, automaatsete testide käivitamist, andmemudeli loomist, analüüside käivitamist, dokumentatsiooni genereerimist ja paigalduspaketi loomist (kui mitte testserverile tõstmist). Seejuures tuleb meelde jätta, et ainult kompileerimine ja analüüside tegemine ei ole pidev integratsioon. Tähtis on, et testid viiakse läbi.
Versiooni numbri uuendamine on kasulik, sest selle järgi on hea vigu kirja panna (need, mis manuaalsetes testides välja tulevad).
Süsteem tuleb kompileerida, et selle kohta analüüse teha ja seda testida. See on küllaltki elementaarne samm.
Järgmisena tuleks läbi viia andmemudeli loomine ja testandmete lisamine. See hoiab ka andmebaasi kenasti integratsiooni osana ning ei teki juhtumeid, kus andmemudel erineb masinatel.
Üks olulisemaid osasid on testide läbiviimine. Testid peavad olema automaatsed, sest muidu ei ole võimalik saada umbes 10 minuti jooksul, kas integreerimine õnnestus või mitte. Soovitatav on käivitada testid mitmes osas: kõige kiiremad esimesena ehk komponendi testid, järgmisena võib käivitada integratsiooni ja funktsionaalsed testid ja pärast seda süsteemi testid. Selle idee seisneb võimalikult kiirelt läbi kukkuda, kui see juhtuma peaks.
Eelviimaseks osaks jääb analüüsimine ja dokumenteerimine. Analüüsida tasub lähtekoodi keerukust, arhitektuurilisi vigu, dubleerimisi ja testide kaetavust. Nende põhjal saavad arendajad ümber struktureerida süsteemi paremuse poole. Dokumentatsiooni osas tasub see genereerida automaatselt ehk vastavalt lähtekoodile, sest kõige hullem on väär dokumentatsioon.
Viimaseks osaks jääb paigalduspaketi loomine. See võib olla kokku pakitud ja valmis avalikkusele nähtavaks teha. Paljud tarkvara arendajad teevad avalikkusele nähtavaks õnnestunud öised integratsioonid (nightly build).
Kui kõik need etapid läbitud või esimese veani jõutud annab pideva integratsiooni server märku asjaosalisele õnnestumise või ebaõnnestumise kohta.
Kes veel kasulikkusest aru ei saanud, siis neile on siin väike spikker:
- Integratsiooni põrgut ei ole
- Pidevalt on olemas tarkvara, mida võib kliendile demonstreerida
- Süsteem on testitud ja see toimub automaatselt. Et integratsioon paremini õnnestuks, siis on arendajad ka sunnitud teste kirjutama.
- Lähtekoodi analüüsid sunnivad arendajaid paremat tööd tegema, sest keegi ei taha öelda, et ma tegin süsteemi, mis sisaldab 4000 arhitektuurilist viga.
- Dokumentatsioon on rohkem kooskõlas lähetekoodiga
- Kiire tagasiside integratsiooni kohta.
Need, kelle meeldib põrgu vannis istuda, võivad jätkata vana harjumise päraselt edasi oodata, millal vesi keema läheb. Kellele põrgu ei meeldi, see võib pidevat integratsiooni võtta taeva mannana ja katlast välja tulla.