Ветвление и слияние — Руководство по разработчике (серия 3 частей)
Я обнаружил методологию потока выпуска после работы с GIT Flow в течение ряда лет. Мне понравился GIT Flow, это просто была удивительная.
Тем не менее, я твердо верю в то, чтобы всегда пробовать новые вещи и постоянно стремиться к улучшению.
Выпуск поток — это модель ветвления и слияния Microsoft. Это то, как они управляют почти всеми развертываниями уровня производства. Они также используют Azure Dev Ops внутренне, и, поскольку я огромный защитник разработчиков, это казалось гораздо лучше.
Они на самом деле используют Azure DevOps и выпуск потока, чтобы развернуть изменения в Azure Dev Ops.
Внизу этой статьи есть несколько ссылок Microsoft с более подробной информацией, но я расскажу здесь об широких концепциях.
Всякий раз, когда разработчик хочет внести изменения, исправление ошибок или функцию, они отражаются от Master. Этим «темам» ветвям рекомендуется быть недолгими и преданными рано. Флаги функций являются огромной частью этой модели.
Как только разработчик закончил работать над изменениями, они слияют обратно в Master. Отключение любых потенциально нарушающих функций с флагами функций.
Когда релиз готов, новая филиала создается с соответствующим именем (релиз/1.2.4.6). Любые окончательные изменения вносятся в документацию или номера версий, а затем производственная сборка начинается из этого отделения.
Просто, верно?
Управление и количество различных ветвей отличаются от потока GIT тем, что существует только одна ветвь с бесконечным сроком службы. Это мастер
Мастер
Все новые работы по разработке, будь то функции или горячие герметики, начинается как филиал от Master. Мастер всегда должен содержать самый современный код, включая любые вновь разработанные функции.
Именно здесь использование флагов функций поступает в свои собственные. Если вы разработчик, работающий над новой функцией, и вы хотите контролировать развертывание, вы оберните код в флаги функций. Таким образом, вы можете медленно управлять развертыванием новой функции, чтобы выбрать пользователей/серверов.
Другим важным моментом в отношении мастера является то, как код объединяется обратно. Это должно быть сделано очень контроллером.
Для меня это политика филиала и запросы на привлечение. Все слияния для мастера должны быть выполнены с помощью запроса на притяжение, которое рассматривается по крайней мере одним человеком. Также требуется, чтобы сборка была успешно выполнена.
Одна из замечательных особенностей Azure Dev Ops заключается в том, что он позволяет запустить конвейер сборки и выполнять запрос только в случае успеха сборки. Если сборка не удается, уведомления отправляются, а запрос на вытягивание не удается. Это фантастический контроль, позволяющий разработчикам получить отзыв в режиме реального времени по поводу их изменений.
Особенности/горячие файлы
Я сгруппировал как функции, так и Hotfix в одном разделе, так как управление этими ветвями работает одинаково.
Если вам нужно изменить кодовую базу, первое, что вы сделали бы, это создать новую филиал из Master. Как и в случае с выпущенным потоком, соглашения об именах сильно различаются. Я склонен придерживаться старомодного «функция/» и «hotfix/».
Если бы я работал в большой команде разработчиков, я бы также использовал имена пользователей. Давая «jeashamdev/feature/featureName ‘.
Сохраните функцию и горячие филиалы недолго. Часто совершайте, совершайте рано и используйте флаги функций, чтобы сохранить контроль
После того, как он будет готов переместить изменение в Master, создается новый запрос на притяжение. При одобрении код объединяется обратно в Мастер.
Важный момент на срочных горячих ископах. Если ошибка найдена в текущем живом релизе, который необходимо исправить до следующего запланированного выпуска, запрос на вытягивание должен быть «забит вишня» в филиале релизов. Но об этом позже…
Чтобы снова взорвать трубу Azure Dev Ops, она предоставляет фантастический пользовательский интерфейс, чтобы сделать этот процесс чрезвычайно простым. После завершения запроса на вытяжение вы можете нажать кнопку вишни, и создается новая ветка, чтобы объединить ваш запрос на вытяжку с выбранной ветвью. Может ли это быть проще?
Выпуск
Когда дело доходит до создания выпуска, из Мастера создается новая филиала. Здесь следует согласовать последовательную конвенцию об именах в вашей команде. Бессмысленное именование ветвей высвобождения вызовет большую путаницу.
Я склонен сохранять это просто и идти с «релизом/».
После того, как филиал выпуска будет создан, должны быть внесены любые последние изменения. Для меня это обычно включает в себя обновление документации, а проверка номеров версий верна.
После того, как он был счастлив, трубопровод CI/CD стартует, чтобы перенести этот ветвь релиза в производство.
Таким образом, у нас есть всеобъемлющая структура модели потока высвобождения, без дальнейших слоев. Давайте прыгнем в какой -то код:
Для этого короткого урока я собираюсь использовать ту же кодовую базу, что и из статьи GIT Flow. Однако, чтобы показать полную мощность этого процесса, я собираюсь использовать Azure Dev Ops. Репо можно найти здесь https://dev.azure.com/jeastham1993/blog-release-flow Анкет
Я собираюсь охватить конфигурацию политик филиалов и автоматических сборок в более позднем посте, поэтому теперь я пропустим это довольно быстро.
Внесение изменений
У меня есть новый запрос функции для моего супер -бесполезного API, который должен добавить новую функцию, которая просто возвращает «Hello Earth».
Для начала я создаю новую ветку. Это может быть сделано либо через веб -интерфейс, либо из окна терминала. Чтобы сохранить это как можно ближе к потоку GIT, я использую терминал.
git cakeout -b функция/addhelloearth
Как только новая филиала была создана на месте, я могу продолжить и внести изменения.
После завершения изменений и любого локального тестирования (как вы можете себе представить, для этой кодовой базы требуется тонны тестирования), я запускаю коммит и толкание.
git добавить server.js git commit -m «[feature] Добавить Hello Earth Endpoint» git push-set-upstream proun feature/Addhelloearth
Если бы ветвь была создана в Azure DevOps и снята, последним шагом был бы просто «git push».
Теперь, когда код предан, у меня есть два филиала в Azure DevOps
При навигации по репо в пользовательском интерфейсе я также получаю удобное небольшое сообщение, сообщая мне о моих выдающихся изменениях.
И это именно то, что я собираюсь сделать. Я создаю запрос на тягу, и новая функция объединена в Master.
Создание релиза
Моя обновленная функция прошла через QA и постановку, и теперь я готов выпустить его в мир.
Для этого я создаю новую филиал из Master с именем release/version_number, внося изменения в мою документацию и выдвигаю его.
GIT Checkout -B Release/1.1.0 git добавить readme.md git commit -m «[ Внутренняя] Обновление документации git push-set-upstream resure/1.1.0
Обычно я выполнил этот шаг в реальном пользовательском интерфейсе Azure Dev Ops. Для сравнения с потоком GIT я держал все это в окне терминала.
После того, как у меня появился производственный конвейер, настроенный в Azure Dev Ops (опять же, один для более позднего поста). Трубопровод наблюдает за любыми изменениями в филиале под названием «Выпуск/*» и подталкивает их к производству.
И неизбежное исправление ошибок
Наш код находится в производстве, и все счастливы. До тех пор, пока команда, которая попросила новую функцию, не поняла, что они запросили не ту. Они на самом деле хотели поздороваться с миром, а не на землю.
Отличные новости…
К счастью, с моделью потока выпуска, это оказывается действительно простым. Так что же нам делать?
Начиная с главной ветви (потому что все ветви поступают от Мастера), я бегал:
git тянутся GIT Checkout -b HotFix/ForrectingFeatRethEStupidTeamaskedFor
Я всегда склонен сначала запускать команду git pull, чтобы убедиться, что все, что у меня есть, обновлено.
Затем я исправил в новой ветви Hotfix и оттолкнул это к моему репо.
Ветвь будет автоматически протестирована, а затем объединена в мастер, это здорово. Это означает, что исправление теперь существует для любой новой добавленной работы, поэтому гарантированно никогда не будет пропущено в более позднем выпуске.
Очевидно, что главная филиала теперь может содержать тонны новых функций, которые не готовы к созданию вживую. Вот где флаги функций играют огромную роль. Однако, используя пользовательский интерфейс Azure Dev Ops, существует фантастический способ объединить изменения.
Вишня
После того, как я объединил свой филиал Hotfix в Master, я получаю это удобное маленькое сообщение, дающую мне возможность для вишни.
Нажав кнопку вишни, я могу быстро выбрать, в какую ветку я хочу объединить это изменение.
Это вполне возможно с использованием стандартных команд GIT, но иметь такой интуитивно понятный интерфейс в Azure Dev Ops — отличный опыт.
По мере того, как производственный конвейер настроен на работу, как только изменение внесено в филиал «Выпуск/*», он просто спускается мгновенно.
Идеальный!
Что мои друзья — поток выпуска! Из двух моделей выпуск Flow намного лучше подходит для того, как работает моя компания. Но есть и плюсы, и минусы использования потока GIT или выпуска.
Добавьте в смесь другие методологии для управления репозитором GIT, и есть много вариантов.
То, что я пытался охватить этими двумя статьями, так это то, что наличие какой -либо стратегии важно.
Не настраивайте систему управления версиями и думайте, что вы закончили, потому что ваш код контролируется.
Не думайте, что вы защищены от простых откатов и простых изменений, потому что ваш код контролируется.
Используйте GIT в полной мере. Ветвь, объединяй и наслаждайся надежностью, которая приходит с этим.
Дальнейшее чтение
https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoft https://trunkbaseddevelopment.com/
Ветвление и слияние — Руководство по разработчике (серия 3 частей)
Оригинал: «https://dev.to/jeastham1993/branching-merging-strategies-release-flow-18f3»