Для версии на основе ветвей нам нужно рассмотреть следующую диаграмму, которая прекрасно иллюстрирует панораму процесса управления конфигурацией. Прежде всего, эта диаграмма написана на основе модели Git, но на самом деле Git и Subversion уже разобрались с концепцией управления контролем версий, хотя Git действительно делает качественный скачок вперёд по сравнению с Subversion в управлении ветками и распределённой производительности (хотя это не основная тема этой статьи).
Прежде чем вводить принцип этого графа, давайте поговорим о двух различных стратегиях общего контроля версий: одна — «пионерский магистраль, стабильная ветвь», а другая — «стабильный магистраль, пионерская ветвь». Как следует из названия, это стабильная версия (производственная версия), на стволе или на ветке. В случае традиционных проектных команд, использующих VSS, трудно сказать, к какому режиму он принадлежит, главным образом потому, что сама VSS не имеет стратегии управления ветками, поэтому многие проектные команды создают соответственно две версионные библиотеки (или три), соответствующие производственной и разработочной среде, конечно, это также своего рода управление ветками под маскировкой. Однако, если переключиться на Subversion или Git как инструмент контроля версий, большинство команд используют режим стабильного транка, то есть trunk (truck или master) соответствует стабильной производственной среде и отмечает разные релизы, чтобы обозначить производственную версию. Лично я считаю, что стабильный основной шаблон кода должен быть абсолютным основным решением для управления версиями кода на данный момент. Приведённая выше картинка — это стандартная модель управления «стабильной магистралью».
мастер: Соответствующая Subversion — грузовик。 В соответствии с производственной версией он отмечается один раз в каждом релизе.
Ветка выпуска (также известная как ветка интеграции): Пока продакшн обновляется, её нужно сначала объединить с веткой релиза (интеграционная ветка). Это отчасти похоже на то, что команда проекта сейчас называет концепцией «предпродакшн» и «симулированной среды».
Разработка ветки (ветка разработки или ветка разработки): Окружение, с которым сталкивается среда разработки.
Feature branch (feature branch): Некоторые независимые функции можно отделить от отдельной ветви разработки. Это в основном для того, чтобы учитывать, что некоторые функции могут долго обновляться, чтобы не затягивать релиз и отдельные ветки.
Ветка хотфиксов (ветка исправления ошибок): Баг здесь в основном производственный.
После введения ствола и ветвей мне нужно представить направление их генерации и слияния.
Master — это производственная версия, и trunk принимает только две ветки для слияния: одна — ветка release (ветка интеграции), другая — ветка горячих исправлений. Ни одна другая ветвь не может быть объединена в производственный филиал.
Ветвь выпуска изначально создаётся одновременно с производством, что и производство. Он принимает ветку разработчика только для слияния с ней. Другими словами, он не принимает слияние напрямую из ветки признаков или ветки исправления ошибок.
Ветвь разработки, ветка разработки, как и ветка интеграции, в определённый момент времени совпадает с производственной средой. Однако по мере продвижения разработки новые функции будут продолжать создаваться на ветке разработки. Dev Theory допускает объединение только двух ветвей: одна — хотфиксы, другая — feature branch.
Feature Branch, начиная с определённой точки (версии) с dev branch, в конечном итоге она сливается с ветвью dev.
Давайте кратко представим метод контроля версий в виде сценария
Предположим, что производственная версия разделена на ветки (dev, хотфиксы, релиз), и в этот момент разработчик начинает разрабатывать в общей сложности десять функций. Когда было разработано 8 из 10 функций, команда тестирования начала вмешиваться во внутреннее тестирование, а администратор конфигурации развернул ветку разработки в среду для тестирования через инструменты непрерывной интеграции (отдельная тема здесь). Когда тестовая проверка показала, что две функции полностью неприемлемы и требуют переработки, такие как простая страховая страховка и возврат претензий, от dev были отделены две feature ветки, соответствующие простому страховому страхованию и возврату претензий, а на ветке разработчика также нужно было откатить соответствующий код (ручное управление здесь). Когда тестовая команда обнаруживает, что с тестом ветки разработки нет проблем, он соответствует условиям UAT, поэтому администратор конфигурации объединяет ветку разработки с веткой релиза, а затем с помощью инструментов непрерывной интеграции публикует эту ветку в предпродакшн-среду и передаёт пользователю для тестирования. Когда пользовательская верификация обнаруживает проблему, разработчик модифицирует ветку разработчика, а затем объединяет её с веткой release (здесь, на оригинальном изображении, она напрямую изменяется в ветке release, я считаю, что это плохо, рекомендую разработчику обращаться только к ветке разработчика), когда процесс верификации релиза внезапно обнаруживает серьёзный баг в окружении сборки, который нужно срочно исправить, он срочно изменяется на ветке хотфиксов и запускается после проверки правильности. Одновременно ветка хотфиксов объединяется с dev (здесь это в основном ручное, потому что на тот момент производственная версия уже сильно отличается от dev-версии, и часто невозможно завершить автоматическое слияние), а затем dev объединяется с релизом. Со временем функция возврата претензий может перестать быть нужна и её нужно отменить, поэтому ветка функции возврата претензий будет удалена. Ещё одна функция легко застраховается, и она была разработана и вновь объединена с отделом разработчиков для запуска следующей онлайн-версии.
Вышеуказанный сценарий в основном включает рутинную разработку, распаковку, экстренные обновления и другие сценарии в ежедневном процессе разработки.
|
Опубликовано 08.04.2018 10:25:39
|
|
|
|
