За версията, базирана на клонове, трябва да говорим за следната диаграма, която перфектно илюстрира панорамата на процеса на управление на конфигурацията. Първо, тази диаграма е написана на базата на Git модела, но всъщност Git и Subversion вече са разбрали концепцията за управление на контрола на версиите, макар че Git прави качествен скок напред в сравнение със Subversion в управлението на клонове и разпределената производителност (но това не е фокусът на тази статия).
Преди да въведем принципа на този граф, нека поговорим за две различни стратегии за общ контрол на версиите – едната е "пионерски гръбнак, стабилен клон", а другата е "стабилен гръбнак, пионерски клон". Както подсказва името, това е стабилната версия (производствена версия), на ствола или на клона. В случая с традиционните проектни екипи, използващи VSS, е трудно да се каже към кой режим принадлежи, главно защото самият VSS няма стратегия за управление на клонове, затова много проектни екипи създават съответно две версионни библиотеки (или три), съответстващи на продукционната и разработната среда; разбира се, това е и вид управление на клонове под прикритие. Въпреки това, ако превключите към Subversion или Git като инструмент за контрол на версиите, повечето екипи използват stable trunk режима, тоест trunk (truck или master) съответства на стабилна продукционна среда и тагва различни издания, за да посочи продукционната версия. Лично аз смятам, че стабилният гръбначен код модел трябва да бъде абсолютното основно решение за управление на версиите на кодовете в момента. Горната снимка е стандартният модел за управление на "стабилен гръбнак".
майстор: Съответната Subversion е камион。 В съответствие с продукционната версия, тя се тагва веднъж при всяко издание.
Release Branch (известен още като интеграционен клон): Докато продукцията е обновена, тя трябва първо да бъде обединена с release branch (интеграционен клон). Това е донякъде подобно на това, което екипът по проекта в момента нарича концепцията "предпроизводство" и "симулирана среда".
Develop branch (dev branch или dev branch): Средата, пред която се сблъсква средата за разработка.
Feature branch (feature branch): Някои независими функции могат да бъдат отделени от отделен клон на разработка. Това е основно, за да се справи с факта, че някои функции може да отнемат сравнително дълго време за обновяване, за да не се забавя издаването и отделянето на клоновете.
Клон за горещи поправки (клон за поправка на бъгове): Бъгът тук е основно производствен бъг.
След като въведа ствола и клоните, трябва да представя посоката на генериране и сливане на тези клони.
Master е продукционната версия, а trunk приема само два клона за сливане – единият е release branch (integration branch), а другият е hotfixes клон. Нито един друг клон не може да бъде обединен в производствен клон.
Release branch първоначално се създава едновременно с продукцията, което е точно същото като производството. Той приема разработката само за да се слее с нея. С други думи, той не приема сливане директно от feature branch или bugfixes branch.
Dev клонът, разработчивият, както и интеграционният клон, е същият като продукционната среда в определен момент от време. Въпреки това, с напредването на разработката, нови функции ще продължат да се създават в dev клона. Dev Theory приема само сливане на два клона – единият е хотфикси, а другият е feature branch.
feature branch, започвайки от определена точка (версия) с dev клона, feature branch в крайна сметка ще се слее с dev branch.
Нека накратко въведем метода за контрол на версиите под формата на сценарий
Да предположим, че продукционна версия е разделена на клонове (dev, hotfixes, release), и по това време разработчикът започва да разработва общо десет функции. Когато бяха разработени 8 от 10-те функции, тестовият екип започна да се намесва за вътрешно тестване, а администраторът на конфигурацията разположи разклонения клон в dev средата за тестване чрез инструменти за непрекъсната интеграция (отделна тема тук). Когато тестовата проверка установи, че две от функциите са напълно неприемливи и трябва да бъдат преработени, като проста застрахователна застраховка и връщане на претенция, два функционални клона бяха отделени от разработката, съответстващи на проста застраховка и възстановяване на искове, а в разработчивия клон съответното кодиране също трябваше да бъде върнат назад (ръчна работа тук). Когато тестовият екип установи, че няма проблем с dev branch теста, той отговаря на условията на UAT, затова администраторът на конфигурацията слива dev клона с release branch и след това използва инструменти за непрекъсната интеграция, за да публикува този клон в предпроизводствената среда и да го предаде на потребителя за тестване. Когато верификацията на потребителя открие проблем, разработчикът модифицира dev клона и след това го слива с release branch (тук, на оригиналната снимка, той е директно модифициран в release branch, мисля, че това не е добре, препоръчвам разработчикът да гледа само към dev клона), когато процесът на верификация изведнъж открие, че има сериозен бъг в build средата, който трябва да се поправи незабавно, той се модифицира спешно в клона hotfixes и се стартира спешно след проверка дали е правилен. В същото време клонът hotfixes се слива с dev (тук е предимно ръчно, защото по това време продукционната версия вече е много различна от dev версията и често е невъзможно да се завърши автоматичното сливане), а след това dev се слива с изданието. След определен период функцията за връщане на искове може вече да не е необходима и да трябва да бъде отменена, затова клонът за връщане на искове ще бъде изтрит. Друга функция е лесна за застраховане и е разработена и отново интегрирана в dev branch, за да пусне следващата онлайн версия.
Горният сценарий основно включва рутинна разработка, разопаковане, спешни актуализации и други сценарии в ежедневния процес на разработка.
|
Публикувано в 8.04.2018 г. 10:25:39 ч.
|
|
|
|
