3 dôvody, prečo začať s verziovaním


  • Zdieľať na Google+

V ostatnom čase intenzívnejšie riešime nábor nových ľudí, pričom sme si všimli zaujímavý trend. Freelanceri a dokonca aj ľudia z malých firiem nemajú žiadnu skúsenosť s verziovaním svojich projektov pomocou všeobecne dostupných nástrojov.

Vo WebSupporte používame dva najrozšírenejšie systémy pre správu verzií, a to GIT a SVN. Momentálne používame viac SVN, ale máme ambíciu postupne premigrovať na GIT. Je mnoho dôvodov, prečo použiť verziovanie, no ja opíšem tie najdôležitejšie pre mňa.

1. Každý projekt má verzie

Neoddeliteľnou súčasťou programovania je inkrementálne pridávanie funkcionality. Ak sa trocha odosobníme od projektu a posnažíme sa naň pozrieť s nadhľadom, tak v podstate každá novonaprogramovaná funkcionalita aplikácie sa dá považovať za verziu. Práve z tohto dôvodu je výhodné mať nástroj, ktorý poskytuje prehľad medzi verziami. Vidím, kedy som čo do projektu pridal, a viem sa jednoducho vrátiť k predošlej verzii projektu. V prípade chyby som pružnejší a viem efektívne vrátiť projekt do predošlého stavu.

2. Aj tím ťaží z verzií

Každý, kto pracoval v tíme bez použitia verziovania, mi určite dosvedčí, že najťažšie je ustriehnuť prepisovanie súborov. Práca je neefektívna a nebezpečná. Pri verziovaní tieto problémy neexistujú. Každý člen tímu má svoju verziu, na ktorej pracuje, zmeny sa neskôr automaticky spoja do jedného celku. Všetci zúčastnení tak majú kontrolu nad svojou prácou a nemusia sa báť nežiaduceho prepisovania.

3. Ukáž mi karty

Verziovanie neskutočne napomáha prehľadnosti a vnáša potrebné svetlo do temného programovania :). Pri odosielaní zmien na server musí každý člen písať správy opisujúce danú zmenu. Toto má za následok prehľadnosť a porozumenie práci ostatných členov tímu. Ku každému riadku v budovanom systéme existuje jeho história. Je veľmi jednoduché pozrieť si kto, čo a kedy robil na danom mieste. Tím sa neskrýva a ľudia vedia, za kým môžu ísť v prípade nejasností.

Ako fungujeme my?

Videl som už viacero spôsobov používania verziovania v rôznych firmách. Niektoré z nich boli štastnejšie, iné menej. Vo WebSupporte sme si zvolili spôsob, ktorý nám umožnil najväčšiu pružnosť a efektivitu pri vývoji a prípadnom fixovaní bugov.
Každý náš projekt je rozdelený na vývojovú a produkčnú vetvu. Produkčná vetva, ako z jej názvu vyplýva, je nasadená v produkcii a je označovaná familiárne slovíčkom „LIVE“. Tu neprebieha vývoj novej funkcionality, na LIVE sa robia len fixy a opravy chýb. LIVE má svoju verziu, podľa interného číslovania. Momentálne sa v produkcii nachádza verzia 1.5.5 a 1.5.6 je už za dverami.
Vývojová vetva slúži na vývoj novej funkcionality, ktorá je rozsiahlejšia a obnáša testovanie a programovanie viacerých ľudí. Výhodou oddelených vetiev je, že v žiadnom prípade sa nám nestane, aby sa nedokončená vec dostala na LIVE a spôsobila tým nestálosť systému, prípadne iný kritický bug.

Tento blogpost som zámerne venoval filozofii a nie technológii. Verím, že tí z Vás, čo doposiaľ nepoužívali verzovanie systému, mu po otestovaní prídu rýchlo na chuť a o pár týždňov si povedia, ako bez neho mohli žiť. Tí, ktorí by sa chceli hlbšie ponoriť do terminológie a významu SVN, tak pre tých som pripravil popis základných častí prvkov SVN.

Komentáre

  • nixone
    Odpovedať
    Autor
    nixone

    Verziovanie ma este jednu ohromnu vyhodu (aspon pre mna), a to ze ked je raz nejaky kod v systeme tak sa vzdy k nemu da vratit a clovek sa neboji prebudovat cast kodu len koli tomu ze bude tazke sa k tomu vratit spat… U mna to podporuje rychlejsi pokrok v kode, preto verziujem vsetky projekty, aj tie o ktorych viem ze pracovny tim nikdy neuzru, a budem na nich makat sam.

    • Ivan Kopčík
      Odpovedať
      Autor
      Ivan Kopčík

      Presne! to co pises su vlastne verzie 🙂 Kazdy subor, riadok ma svoju historiu (verziu) a teda je jednoduche sa vratit do akehokolvek stavu.

  • Tomy
    Odpovedať
    Autor
    Tomy

    hmm…pekny clanok…ale mna by skor zaujimalo akym sposobom sa rozny developeri rozhoduju ze prejdu z verzie 1.01.12.09 na verziu 2.00…tomuto verziovaniu ja nerozumiem…a podla coho si vlastne vyskladaju takuto krkolomnu verziu, pre uzivatelov absolutne irelevantnu lebo nikto si nebude pametat ze v 1.01.12.10 je uz nieco ine…ale mozno som odbocil tak pardon;)

    • Ivan Kopčík
      Odpovedať
      Autor
      Ivan Kopčík

      Z mojho pohladu maju verzie 2 vyznami. A to je interny, tim vie, v akom stave sa projekt nachadza a na com pracuje. Externy, ten je pre klientov, zakaznikov a sice, ze vidia progress na projekte. Ak sa zmeni verzia, clovek podvedome vnima napredovanie. Oznacenie verzii nepodlieha ziadnym standardom, je to v podstate interna vec kazdej firmy, timu ludi kooperujucich na jednom projekte

    • Vladimir Chovanec
      Odpovedať
      Autor
      Vladimir Chovanec

      Odporucam precitat si http://semver.org

      V skratke (pre verziu x.y.z):
      – bugfix by mal zvysit z (1.2.3 -> 1.2.4)
      – nova spatne kompatibilna ficurka y (1.2.3 -> 1.3.0)
      – nova spatne nekompatibilna ficurka x (1.2.3 -> 2.0.0)

      Tieto pravidla sa oplati dodrziavat najma pre kniznice, ktore su zahrnute vo viacerych projektoch. V praxi to zial nie je take jednoduche.

  • Lukas
    Odpovedať
    Autor
    Lukas

    migracia na GIT bude chciet nejake tie nervy a cas ale urcite sa oplati.

  • Matj
    Odpovedať
    Autor
    Matj

    Super vysvetlenie. Este keby ste motivovali aj vasich adminov a urobili SVN alebo GIT hosting aj u vas 🙂

    • Tom
      Odpovedať
      Autor
      Tom

      Súhlasím.

    • Vlado
      Odpovedať
      Autor
      Vlado

      SVN je pasé, podľa mňa nemajú najmenší dôvod rozbehávať to na hostingu. A čo sa týka DVCS, tak existuje už veľa hotových riešení ako Bitbucket, Github, či Gitlab, takže do toho by som sa už vôbec nepúšťal. 😉

    • Jakub Senko
      Odpovedať
      Autor
      Jakub Senko

      Nooo, mať hosting, ktorý ovládam cez git by bolo špičkové!

  • Ivan
    Odpovedať
    Autor
    Ivan

    Presne tak, aj ja by som repozitáre najradšej hostoval tu na Slovensku, kde nehrozí, že to niekto svojvoľne zhabe.

    • Ivan Kopčík
      Odpovedať
      Autor
      Ivan Kopčík

      Vselico pripravujeme 😉

  • Michal
    Odpovedať
    Autor
    Michal

    super clanok, tiez pouzivam SVN, niektore veci sa mi tymto clankom viac ujasnili.
    Mohli by ste uviest dovody preco planujete premigrovat na GIT?

  • Daniel Andrascik
    Odpovedať
    Autor
    Daniel Andrascik

    SVN je parada vecicka, pouzivam i na svoje sukromne standalone projekty. Uplne mi staci ked pouzivam SVN v offline mode priamo s uloziskom na mojom disku

  • com
    Odpovedať
    Autor
    com

    Nastroj na verzovanie mi pomaha udrziavat psychicku rovnovahu 🙂
    Je skoda ze ste v blogu nespomenuli mercurial, je to paradny nastroj aj pre zaciatocnikov.
    http://tortoisehg.bitbucket.org/

    Pre tych ktory chcu git odporucam toto:
    http://code.google.com/p/tortoisegit/

  • Stefan Huska
    Odpovedať
    Autor
    Stefan Huska

    Velmi dôležitý článok.

    Pre tých čo chcú mať poriadok v príkazoch a branchiach a používaju GIT, odporúčam používať rozšírenie GIT FLOW. https://github.com/nvie/gitflow Integruje sa do shellu.

    Rieši featury, verzie, hotfixy a releasy.

  • Pali
    Odpovedať
    Autor
    Pali

    Nice intro.

    V každom prípade, kto na netímové projekty nepoužíva verzionovanie, škodí sám sebe. Ja používam GIT už skoro 2 roky a nedám dopustiť (aj keď mercurial sa mi javí užívateľsky príjemnejší). Všetky moduly som donedávna pridával do projekty cez git submoduly, odvtedy, čo SilverStripe switchlo na composer (getcomposer.org, čo je vlastne dependency manažér prvotne postavený pre symphony), tak všetko inštalujem už len cez to…

    Ohľadne repohostingu, skúste repositoryhosting.com – za rok prevádzky a 80 repozitárov ani jeden jediný problém. Ešte keby som vedel „gitovať“ u zákazníkov s vlastným hostingom a následne „composer install“ a som v raji…

    pre projekty