Minulý týždeň sme počas tréningu agilných praktík diskutovali s tímami okrem iného aj praktiky, ktoré používajú pre správu verzií kódu.
Tím zaujal koncept tzv. Changesetu. Je to logický celok, ktorý zahŕňa všetky zmeny potrebné pre implementáciu požiadavky. Zmeny môžu byť uložené vo viacerých súboroch.
Changeset umožňuje pracovať s celou požiadavkou ako jedným balíčkom, ktorý sa môžeme rozhodnúť publikovať, alebo naopak stiahnuť z pripravovanej verzie. Pre tím to bola nová technika aj keď v nástrojoch ako napr. Microsoft TFS je už dlho používaná, nevraviac o Git alebo Mercurial.
Tímy dnes k verziovaniu pristupujú týmto postupom:
- Commitujú prakticky každú zmenu, dokonca niekoľkokrát denne len kvôli tomu, aby mohli medzi sebou zdieľať posledné zmeny. Takže kód sa prakticky mení neustále pod rukami čo robí integráciu nemožnou.
- Používajú viacero trunkov, vyvíjajú paralelne viacero verzií.
- Nepoužívajú branch/merge operácie a teda každú zmenu musia zopakovať v každej release vetve. To spomaľuje celý proces vývoja.
Najväčšie prekvapenie však prišlo až po tréningu. Produkt je postavený v podstate ako interpretačné jadro a nadstavba pre spracovanie skriptov a formulárov. Nástroj Dizajnér, ktorým definujú nadstavbové rozšírenia, v podstate uchováva všetky entity projektu (formuláre atď.) v jednom XML súbore. Takže tu je ten koreň vyššie uvedených praktík používaných pre správu verzií.
Zmena jedného formulára zablokuje celý tím. A ten tak musí robiť na viacerých kópiách (trunkoch) alebo jednoducho čakať pokiaľ vývojár neuvoľní svoju zmenu. Tím tak nemá možnosť správne aplikovať praktiky kvôli nástroju. Navyše nástroj nie je jednoduché meniť, pretože sa používa už niekoľko rokov a zmeniť ho by neprinieslo dodatočnú hodnotu. Jednoducho čas na jeho generačný posun, resp. náhradu.
V dobe, keď nástroj vznikol, bol tento prístup moderný. Veď mnohí si ešte pamätáme XMLizáciu všetkého. A aj to, že v SourceSafe bolo bežné zamknúť menený súbor a zamedziť tak ostatným v tíme spraviť ‚zlú zmenu‘.
Ako použiť nástroj pre správu verzií
- Plánujte malé user stories. To vás navedie k malým zmenám, ktoré je ľahké integrovať.
- Naučte sa používať changesety ak to nástroj dovoľuje.
- Často integrujte váš počítač s hlavným trunkom.
- Spravte merge operáciu a následné pretestovanie pred commitom svojich zmien.
- Commit robte iba ak je zmena otestovaná. Nezabudnite na unit testy ak majú zmysel.
- Dohodnite si pravidlá popisovania zmien. Komentár k zmene vždy pomôže. Najmä keď je potrebné zmeny vrátiť.
- Používajte štítky (labels, tags) ak to nástroj dovoľuje.
- Udržujte čo najmenší počet vetiev (branch). Dnes je však časté použitie aspo§ dvoch vetví (main, develop)
- Snažte sa vyhnúť dlhému obdobiu kedy nemergujete. Inak budete mať neskôr vážny problém udržať produkt funkčný.
Agile nie je iba Scrum
Zavedenie Agile sa (bohužiaľ) často mení iba na zavedenie Scrum. Pred zavedením agilných praktík preto nezabudnite prehodnotiť, či nie je na čase zmeniť viac než len prístup k projektovému manažmentu.
Zamyslite sa ako vyzerá váš produkt zvnútra a ako sa produkt vytvára. Ak sa nedá na produkte pracovať v malých tímoch a paralelne, potom to môže byť aj hlavná príčina prečo ani Agile nemusí pomôcť.
Takáto väčšia zmena vás síce na začiatku spomalí, no investícia sa určite vyplatí neskôr keďa sa pridá aj samoorganizácia.
