Šį kartą blogo straipsnis ne apie patį Scrum, o apie vieną iš standartinių programinės įrangos kūrimo procesų: kodo versijų ir saugyklos valdymą. Aišku, nagrinėsime kaip tai daroma judriuose (agile) projektuose. Pačiam teko nemažai diskutuoti šia tema diegiant Scrum, o visai neseniai radau puikų straipsnį apie tai „Versijų valdymas su keliomis judriomis komandomis”: http://www.infoq.com/articles/agile-version-control.
Tikiuosi kad visi, skaitantys šį blogą savo projektų kodą saugo kodo saugyklose (pvz SVN). Taip pat spėju, kad daugelis puikiai žinote vadinamąją „SVN book” kurioje aprašomos siūlomos kodo saugyklos struktūros: http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html ir kodo šakų bei versijų valdymo procedūros: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html. Turbūt, daugelis jomis ir vadovaujatės. Puiku! Bet pažiūrėkime kas iš šių siūlomų sprendimų nelabai tinka projektus kuriant judriais metodais.
Kodo laikymo struktūra saugykloje
“SVN book” siūlo kodą struktūrizuoti pagal projektus, kurių kiekvienas turi savo „Trunk” „Branches” ir „Tags”. Tai aišku puikiai veikia kol projektai yra visiškai nepriklausomi vienas nuo kito. Deja, praktika rodo, kad daugelis projektų iš tikrųjų yra produktų sudedamosios dalys. Šie projektai, labai dažnai yra ne kas kita kaip sistemos architektūriniai komponentai, kurie vienas su kitu gan glaudžiai susiję. Pakeitus ką nors viename projekte, tai gali įtaturėti įtakos kitam projektui (pvz pakeitėme duomenų perdavimo protokolą tarp dviejų to paties produkto komponentų). Naudojant „SVN book” siūlomą struktūrą, šios problemos bus pastebėtos gan vėlai, tik integracijos testavimo procese.
Judrios techninės praktikos siūlo integracijos testavimą atlikti nuolat, pradedant pirma projekto gyvavimo diena. Tai reiškia, kad visas produktas (nepriklausomai kiek turi susijusių projektų) turėtų būti automatiškai kompiliuojamas ir testuojamas kasdien, kad bet koks netikėtas pakeitimas viename projekte (produkto komponente), nepaveiktų kito projekto (produkto komponento). O jei jau paveikė, kad ta klaida būtų pastebėta tik atsiradusi. Be abejo, tai yra daug lengviau padaryti turint visus projektus (komponentus) po viena kodo saugyklos šaka, negu kai visi projektai turi savo atskiras šakas (trunk, branches, tags).
Kodo kasdienis kėlimas į saugyklą
„SVN book” siūlo kodą kelti į saugyklos Trunk šaką kas dieną. Kai kodas jau artėja prie paleidimo, siūloma jį kopijuoti į paleidimo šaką (Branch), ten atlikti stabilizavimą, kol likusios komandos toliau programuoja į Trunk.
Tuo tarpu judrus projektų kūrimo procesas reikalauja turėti visada paleidžiamą „releasable” produktą. Scrum terminais tai reiškia, kad kodas turi būti pasiekęs pabaigtą (Done) kriterijų: analizuotas, sukoduotas, ištestuotas, dokumentuotas, aprašytas ir pademonstruotas klientui (žr. Pirmas blynas iškeptas prezentacijos 33 skaidrę). Taigi „Trunk‘e” turėtų būti „Pabaigtas” arba, kitais žodžiais, visada paleidžiamas kodas.
Betgi kodą reikia kelti į saugyklą kuo dažniau! Pabaigti funkcionalumo per dieną irgi nepavyks! Ką daryti?! Naudojant judrų projektų kūrimą siūloma pradedant kurti naują funkcionalumą (kuris yra labai plonas funkcionalumo pjūvis per visus techninius produkto sluoksnius), nusikopijuoti Trunk į šaką (Branch). Tuomet komanda šioje šakoje atlieka programavimą ir testavimą. Taip pat komanda nepamiršta kasdien pasitikrinti ar nieko naujo neatsirado Trunk‘e (kitos komandos nepadėjo pilnai pabaigto funkcionalumo). Jei atsirado, tada komanda turi sulieti (merge) visus pokyčius ir dar kartą įsitikinti jog jų komandos kodas puikiai veikia su viso produkto kodu. Kai komanda pilnai baigia funkcionalumą (pagal pabaigos (Done) kriterijų), jie perkelia kodą į Trunk.
Išleistų versijų perkėlimas į „Tag” šakas, atliekamas taip pat kaip ir standartiniame procese, po tikrojo paleidimo (release).
Grafinė reprezentacija (iš http://www.infoq.com/articles/agile-version-control)
Taigi tokie yra pagrindiniai skirtumai. Turite klausimų ar komentarų? Komentuokite!