Pro verzi založenou na větvích musíme mluvit o následujícím diagramu, který dokonale ilustruje panorama procesu správy konfigurace. Za prvé, tento diagram je napsán na základě modelu Git, ale ve skutečnosti Git a Subversion už pochopily koncept správy verzování, ale Git dělá kvalitativní skok vpřed oproti Subversion v oblasti správy větví a distribuovaného výkonu (ale to není hlavní téma tohoto článku).
Než představíme princip tohoto grafu, pojďme si probrat dvě různé strategie obecné verzní kontroly, jedna je "pionýrská páteř, stabilní větev" a druhá "stabilní páteř, pionýrská větev". Jak název napovídá, jedná se o stabilní (produkční verzi), na kmeni nebo na větvi. V případě tradičních projektových týmů používajících VSS je obtížné určit, do kterého režimu patří, hlavně proto, že VSS sám nemá strategii řízení větví, takže mnoho projektových týmů vytváří dvě (nebo tři) knihovny verzí, odpovídající produkčnímu a vývojovému prostředí, což je samozřejmě také určitý druh správy větví v přestrojení. Pokud ale přepnete na Subversion nebo Git jako nástroj pro správu verzí, většina týmů používá režim stable trunk, tedy trunk (truck nebo master) odpovídá stabilnímu produkčnímu prostředí a označuje různé verze pro označení produkční verze. Osobně si myslím, že stabilní páteřní kódový vzor by měl být absolutně hlavním řešením pro správu verzování kódu v současnosti. Výše uvedený obrázek ukazuje standardní model správy "stabilní páteř".
Mistr: Odpovídající Subverze je nákladní auto。 V souladu s produkční verzí je označen jednou při každém vydání.
Release branch (také známý jako integrační větev): Pokud je produkce aktualizována, musí být nejprve sloučena do větve release (integrační větve). Je to do jisté míry podobné tomu, co projektový tým v současnosti nazývá konceptem "předprodukce" a "simulovaného prostředí".
Větev vývoje (větev vývoje nebo větev vývoje): Prostředí, kterému rozvojové prostředí čelí.
Feature branch (feature branch): Některé nezávislé funkce lze oddělit od samostatné vývojové větve. Hlavním důvodem je vyřešení faktu, že některé funkce mohou trvat poměrně dlouho, než se aktualizují, aby se nezpomalilo vydání a oddělené větve.
Větev hotfixes (větev oprav chyb): Chyba je zde hlavně produkční chyba.
Po představení kmene a větví musím představit směr jejich generování a slučování.
Master je produkční verze a trunk přijímá pouze dvě větve pro sloučení, jedna je release branch (integrační větev) a druhá je větev hotfixes. Žádná jiná pobočka nemůže být sloučena do výrobní větve.
Větev vydání je původně vytvořena současně s produkcí, což je přesně totéž jako produkce. Vývojářskou větev přijímá jen proto, aby se s ní sloučil. Jinými slovy, nepřijímá přímé slučování z větve funkcí nebo oprav chyb.
Vývojová větev, vývojová větev, stejně jako integrační větev, je v určitém okamžiku stejná jako produkční prostředí. Jak vývoj pokračuje, nové funkce budou na vývojové větvi nadále vytvářeny. Teorie vývoje přijímá sloučení pouze dvou větví, jedné jsou hotfixy a druhé větve rysů.
větev funkcí, začíná určitým bodem (verzí) s vývojovou větví, se větev funkcí nakonec sloučí s vývojovou větví.
Pojďme si stručně představit metodu verzní správy ve formě scénáře
Představme si, že produkční verze je rozdělena do větví (dev, hotfixes, release) a v tuto chvíli vývojář začne vyvíjet celkem deset funkcí. Když bylo vyvinuto 8 z 10 funkcí, testovací tým začal zasahovat pro interní testování a správce konfigurace nasadil vývojovou větev do vývojového prostředí pro testování pomocí nástrojů pro kontinuální integraci (samostatné téma zde). Když testovací ověření zjistilo, že dvě funkce jsou zcela nepřijatelné a je třeba je přepracovat, například jednoduché pojištění pojištění a vrácení pojistných událostí, byly odděleny dvě větve funkcí, odpovídající jednoduchému pojištění pojištění a vrácení pojistných událostí, a na vývojové větvi bylo třeba vrátit zpět odpovídající kód (zde ruční ovládání). Když testovací tým zjistí, že s testem vývojové větve není problém, splňuje podmínky UAT, takže správce konfigurace sloučí vývojovou větev s release větví a poté pomocí nástrojů pro kontinuální integraci tuto větev publikuje do předprodukčního prostředí a předá ji uživateli k testování. Když uživatelská verifikace najde problém, vývojář upraví vývojovou větev a pak ji sloučí s release větví (zde je na původním obrázku přímo upravena v release větvi, což si myslím, že není dobré, doporučuji vývojáři čelit pouze vývojářské větvi), když proces ověření release náhle zjistí, že v buildovém prostředí je vážná chyba, kterou je třeba okamžitě opravit, pak je to naléhavě upraveno na větvi hotfixes a po ověření správnosti je urgentně spuštěno. Současně se větev hotfixes sloučí s vývojem (zde je to většinou ruční, protože produkční verze je už velmi odlišná od vývojové verze a často není možné dokončit automatické sloučení), a poté je vývoj začleněn do vydání. Po určité době už funkce vrácení nároku nemusí být potřeba a je nutné ji zrušit, takže větev funkce vrácení nároku bude smazána. Další funkce je snadno pojišťovatelná a byla vyvinuta a znovu sloučena s vývojářskou větví, aby mohla být dostupná s další online verzí.
Výše uvedený scénář v podstatě zahrnuje rutinní vývoj, rozbalování, nouzové aktualizace a další scénáře v každodenním vývojovém procesu.
|
Zveřejněno 08.04.2018 10:25:39
|
|
|
|
