Kodo versijų ir saugyklos valdymas judriuose (agile) projektuose

Šį 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. http://scrum.blogas.lt/pirmas-blynas-iskeptas-27.html 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!

Tagged with: , , , ,
Posted in Agile, Agile praktikos, Kodo valdymas
8 comments on “Kodo versijų ir saugyklos valdymas judriuose (agile) projektuose
  1. Darius Damalakas says:

    Ačiū už straipsnį.

    Po truputį centralizuotos sistemos prarandą rinką decentralizuotoms, tokioms kaip Mercurial (hg), git, arba Bazzar (bzr).

    svn’as dar tikrai išliks ilgam, kalbos nėra. Praktiškai tai yra pirmoji alternatyva kuri kyla į galvą, jei nebūtų decentralizuotų sistemų.

    keletas nuorodų kurias gal ne iš pirmo karto google išmes:

    http://martinfowler.com/bliki/VcsSurvey.html
    http://ddnet.wordpress.com/2010/04/03/branching-in-mercurial/

  2. Dėkui už komentarą ir nuorodas Dariau.

    Mano idėja buvo susikoncentruoti ties procesu nepriklausomai nuo įrankio. Manau bet kokiai kodo saugyklai galima būtų pritaikyti aprašytą procesą jei komanda naudoja Agile metodus (Scrum ar bet kurį kitą). Galbūt klystu 😉 Visgi pagrindinė mano patirtis yra su SVN, tad kitų nuomonės/siūlymai yra labai įdomu.

    Vaidas

  3. Darius Damalakas says:

    Total agree.

    SVNas yra geras įrankis, kuris “does the right job right”. Tiesiog yra dar geresnių įrankių, bet čia visada galima nuklysti į kraštutinumus.

    Šiaip esi pirmas manos sutiktas žmogus ne programeris kuris domisi Agile. Programuotojų daug domisi Agile, bet projektų vadovų – mažai. Todėl labai sveikintina iniciatyva 😉

  4. Hm.. įdomus tavo pastebėjimas dėl programuotojų vs. projektų vadovų 😉 aš apskritai pasakyčiau jog mažai Lietuvoj apie Agile kalbama/daroma, arba visi labai pasislėpę 😉 Todėl ir buvo noras pradėti blogą.

    Ateityje yra planų daryti susitikimus, kad programuotojai, testuotojai, projektų vadovai, vadovai galėtume susitikti, pasidalinti geriausiomis praktikomis ir taikyti Agile daugiau kompanijų.

    Kaip suprantu vieną suinteresuotą (tave) jau turiu. Lauksim kol atsiras daugiau! 😉

    Vaidas

  5. Andrius says:

    Įdomus įrašas. Visai naudinga būtų ir daugiau šia tema 🙂

  6. Dėkui Andriau. Pasistengsiu ateity daugiau. Jei gali patikslink kas konkrečiau šia tema domina?

  7. Andrius says:

    Dėkui :), lauksiu naujų įrašų. Dar būtų įdomu arčiau praktikos scrum metodikos taikymo pavyzdžių. Daugiau mažiau jau galima susidaryti vaizdą, bet dar kažko trūksta. Kol kas tik trumpai peržvelgiau scrum asociacijos puslapį, bet nepastebėjau, kokią programinę įrangą naudoti, siekiant užtikrinti, kad tokiu principu būtų valdomas projektas? (Sorry, jei kvailas klausimas gal tik nepastebėjau) 🙂

  8. Sveikas Andriau. Kvailu klausimų nebūna, tad klausk drąsiai.

    Padedu Scrum įdiegti jau antroje organizacijoje, tad šia patirtimi tikrai planuoju pasidalinti bloge artimiausiu metu. Džiugu kad tai domina.

    Dėl programinės įrangos naudojimo tai manau yra rimta priežastis kodėl nieko neradai Scrum asociacijos puslapyje 😉 Iš esmės, Agile/Scrum yra principai, kuriuos gan lengva suprasti, bet labai sunku idiegti ir išlaikyti organizacijoje. Dar daugiau, Scrum/Agile yra apie žmones ir jų bendradarbiavimą. Tad programinė įranga čia yra tik palaikanti funkcija. Iš esmės, jei organizacija yra iki 50 žmonių tai apskritai programinės įrangos palaikyti procesui praktiškai nereikia 😉 Abiejose kompanijose kur diegiau Scrum planavimą darom naudojant limpančius lapukus ant flip charto, ir praktika rodo, kad tai vienas iš geriausių įrankių 🙂

    Anyway, parašysiu kada daugiau apie tai. O kolkas siūlau užsukti į http://agilemanifesto.org/ puslapį ir pasiskaityti 4 vertybes ir 12 principų ant ko stovi visas agile. Pats pirmasis ir sako: “…mes vertiname žmones ir jų bendravimą labiau nei procesą ir įrankius”.

    Geros dienos!

1 Pings/Trackbacks for "Kodo versijų ir saugyklos valdymas judriuose (agile) projektuose"
  1. […] aprašiau straipsnyje „Kodo versijų ir saugyklos valdymas judriuose (agile) projektuose” (http://scrum.blogas.lt/kodo-versiju-ir-saugyklos-valdymas-judriuose-agile-projektuose-56.html). Jie turėjo funkcionalumo šakas (feature branches) kuriose dirbdavo komandos kol pilnai […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausios mokymų klasės
Data Mokymai - Lektorius
2017 m. gruodžio 14-15 d. Certified Scrum Master (CSM) - Alexey Krivitsky (anglų kalba)
2017 m. gruodžio 14-15 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (anglų kalba)
2018 m. sausis-vasaris (bus paskelbta) Certified Scrum Product Owner (CSPO)
2018 m. sausio 26 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (lietuvių kalba)
2018 m. vasario 8-9 ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (lietuvių kalba)
2018 m. Management 3.0 Change and Innovation Practices
2018 m. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (lietuvių kalba)
2018 m. Better Retrospectives - Jeff Campbell (anglų kalba)
2018 m. Kanban System Design (KMP I) - Gaetano Mazzanti (anglų kalba)
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 686 32487

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 686 32487