Pre verziu založenú na vetve musíme hovoriť o nasledujúcom diagrame, ktorý dokonale ilustruje panorámu procesu správy konfigurácie. V prvom rade, tento diagram je napísaný na základe modelu Git, ale v skutočnosti Git a Subversion už pochopili koncept správy verzií, no Git robí kvalitatívny skok vpred oproti Subversion v oblasti správy vetiev a distribuovaného výkonu (ale to nie je zameranie tohto článku).
Predtým, než predstavíme princíp tohto grafu, poďme sa porozprávať o dvoch rôznych stratégiách všeobecného riadenia verzií: jedna je "priekopnícka chrbtica, stabilná vetva" a druhá "stabilná chrbtica, priekopnícka vetva". Ako názov napovedá, ide o stabilnú verziu (produkčnú verziu), na kmeni alebo na vetve. V prípade tradičných projektových tímov používajúcich VSS je ťažké povedať, do ktorého režimu patrí, hlavne preto, že VSS samo nemá stratégiu riadenia vetviev, takže mnohé projektové tímy vytvárajú dve (alebo tri) knižnice verzií, ktoré zodpovedajú produkčnému a vývojovému prostrediu, samozrejme, ide aj o druh správy vetiev v prestrojení. Ak však prepnete na Subversion alebo Git ako nástroj na kontrolu verzií, väčšina tímov používa režim stabilného trunku, teda trunk (nákladné auto alebo hlavný) zodpovedá stabilnému produkčnému prostrediu a označuje rôzne vydania na označenie produkčnej verzie. Osobne si myslím, že stabilný základný kódový vzor by mal byť absolútne mainstreamovým riešením na správu verzií kódu v súčasnosti. Obrázok vyššie zobrazuje štandardný model riadenia "stabilnej chrbtice".
majster: Príslušný Subversion je nákladné auto。 V súlade s produkčnou verziou je označená raz pri každom vydaní.
Release branch (známy aj ako integračná vetva): Pokiaľ je produkcia aktualizovaná, musí byť najskôr zlúčená do vetvy (integračnej vetvy). Je to do istej miery podobné tomu, čo projektový tím momentálne nazýva konceptom "predprodukcia" a "simulované prostredie".
Vývojová vetva (vývojová vetva alebo vývojová vetva): Prostredie, ktorému čelí rozvojové prostredie.
Feature branch (feature branch): Niektoré nezávislé funkcie možno oddeliť od samostatnej vývojovej vetvy. Je to hlavne kvôli tomu, že niektoré funkcie môžu trvať relatívne dlho na aktualizáciu, aby sa nezaťažilo vydanie a samostatné vetvy.
Vetva hotfixes (vetva opravy chýb): Chyba je tu hlavne produkčná.
Po predstavení kmeňa a konárov musím určiť smer generovania a zlučovania týchto vetiev.
Master je produkčná verzia a trunk prijíma len dve vetvy na zlúčenie, jedna je vetva pre vydanie (integračná vetva) a druhá je vetva hotfixes. Žiadna iná vetva nemôže byť zlúčená do produkčnej vetvy.
Vetva vydania sa pôvodne vytvára súčasne s produkciou, čo je presne to isté ako produkcia. Prijíma vývojársku vetvu len na zlúčenie s ňou. Inými slovami, neakceptuje zlučovanie priamo z vetvy funkcií alebo vetvy opráv chýb.
Vývojová vetva, vývojová vetva, rovnako ako integračná vetva, je rovnaká ako produkčné prostredie v určitom čase. Avšak ako vývoj pokračuje, nové funkcie sa budú naďalej vytvárať na vývojárskej vetve. Teória vývoja akceptuje zlúčenie iba dvoch vetiev, jednej sú hotfixy a druhej vetvy vlastností.
Feature branch, začínajúc v určitom bode (verzii) s vývojárskou vetvou, feature branch sa nakoniec zlúči s vývojárskou vetvou.
Stručne predstavme metódu verzovania vo forme scenára
Predstavme si, že produkčná verzia je rozdelená na vetvy (dev, hotfixes, release) a v tom čase vývojár začne vyvíjať celkovo desať funkcií. Keď bolo vyvinutých 8 z 10 funkcií, testovací tím začal zasahovať do interného testovania a správca konfigurácie nasadil vývojársku vetvu do vývojového prostredia na testovanie pomocou nástrojov na kontinuálnu integráciu (samostatná téma tu). Keď testovacie overenie zistilo, že dve funkcie sú úplne neprijateľné a treba ich prerobiť, napríklad jednoduché poistenie poistenia a vrátenie nárokov, boli oddelené dve vetvy funkcií, ktoré zodpovedali jednoduchému poisteniu poistenia a refundácii nárokov, a na vývojárskej vetve bolo potrebné vrátiť aj príslušný kód (manuálna operácia tu). Keď testovací tím zistí, že s testom vetvy vývoja nie je problém, spĺňa podmienky UAT, takže administrátor konfigurácie zlúči vetvu vývoja s vetvou vydania a potom pomocou nástrojov na kontinuálnu integráciu publikuje túto vetvu do predprodukčného prostredia a odovzdá ju používateľovi na testovanie. Keď overenie používateľa nájde problém, vývojár upraví vývojársku vetvu a potom ju zlúči do vetvy (tu, na pôvodnom obrázku, je to priamo upravené v vetve vydania, čo si myslím, že nie je dobré, odporúčam, aby vývojár čelil iba vývojárskej vetve), keď proces overovania verifikácie vydania náhle zistí, že v prostredí je vážna chyba, ktorú treba okamžite opraviť, potom sa to urgentne upraví na vetve hotfixes a po overení správnosti sa urgentne spustí. Zároveň sa vetva hotfixes zlúči s vývojom (tu je to väčšinou manuálne, pretože produkčná verzia je už teraz veľmi odlišná od vývojárskej verzie a často nie je možné dokončiť automatické zlúčenie), a potom sa vývojár zlúči do vydania. Po určitom čase už nemusí byť funkcia vrátenia nároku potrebná a bude potrebné ju zrušiť, takže vetva funkcie vrátenia nároku bude vymazaná. Ďalšia funkcia je ľahko poistiteľná a bola vyvinutá a opäť zlúčená s vývojárskou vetvou, aby bola spustená s ďalšou online verziou.
Vyššie uvedený scenár v podstate zahŕňa rutinný vývoj, rozbaľovanie, núdzové aktualizácie a ďalšie scenáre v každodennom vývojovom procese.
|
Zverejnené 8. 4. 2018 10:25:39
|
|
|
|
