18 ноября 2012 в 14:51

Простой релиз-менеджмент средствами Git из песочницы tutorial

image
Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).



Как решить эту проблему



Первое что можно сделать – ввести вспомогательную ветку release, в которую делается регулярный merge из master (скриншот сделан в TortoiseGit, timeline снизу-вверх). Для maven-проектов в момент merge в pom-файлах версия SNAPSHOT заменяется на релизную. Если все сделано правильно, это единственный конфликт. Желательно ставить тег с номером версии. После этого в ветке master делается major-up SNAPSHOT-версии, таким образом master всегда SNAPSHOT, release – всегда нет. Соответственно, build-сервер настроен на ветку release для production-сборок.
Недостатком варианта с двумя ветками master и release является невозможность сделать хотфикс, не выпуская новую функциональность из master, что может быть критично.

Вводим ветку hotfix


Для этого можно ввести ветку hotfix, которая будет расти из коммита, предшествующего merge’у в release. Первым коммитом в этой ветке будет minor-up SNAPSHOT-версии (на иллюстрации — 1). Далее сделанные исправления мержатся на ветки release и master. При merge в release разрешается единственный конфликт в пользу фиксации не-SNAPSHOT-minor-версии (2), при merge в master версия остается из master (3). После merge в release в ветке hotfix делается minor-up SNAPSHOT-версии (4). Перед очередным major-релизом hotfix мержится в master – таким образом мы не потеряем все исправления. После окончания подготовки веток они отправляются в origin-репозиторий.

Что имеем в итоге

Основные плюсы решения:
  • наведение порядка с релизами; одной релизной версии соответствует ровно один коммит
  • за счет регулирования прав на репозиторий четко разделяются роли в команде: разработчик, ревьювер, тестировщик / релиз-менеджер
  • в случае нормального хода вещей не приходится делать push --force, рискуя затереть чужие правки, вероятность потерять ценные изменения минимальна
  • Нет необходимости регулярно создавать новые конфигурации по шаблону на билд-сервере (в отличие от варианта создания новой ветки на каждый major-релиз)
  • Схема относительно проста, при этом вполне удобна. Мы используем варианты с двумя и тремя ветками почти во всех своих проектах.

К минусам можно отнести невозможность выпуска hotfix в предыдущем major-релизе. Также невозможно набрать релиз только из нужных коммитов. Это решается усложнением flow и выходит за рамки данной статьи.

Для многих здесь нет ничего нового, но судя по тому же github, аболютное большинство open-source проектов использует самую простую схему с одной веткой.

А какой flow используете вы?

Полезные ссылки: ProGit, Git How To
Sergey @seregamorph
карма
3,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (8)

  • +1
    нам пришлось слезть с git-flow — нет ветки, где можно тестировать накапливающиеся хотфиксы.
  • +2
    Использую очень простой, но понятный flow. Для каждой major версии создается ветка v1.0.0, v1.5.0, дальше именно с этой ветки выпускаются релизы. Например, в ветке v1.0.0 могут быть теги v1.0.0, v1.0.1 или pre1.0.0a, pre1.0.0b

    Никакой ерунды по поводу слияния changes в release ветку не делаю, так как запросто можно потерять суть происходящего. Hotfix вещь очень дорогая для тестирования и поставки, поэтому изменения должны быть максимально прозрачны. Изменения перекидываю из мастера в ветку чудо-командой git cherry-pick.
    Каждый хотфикс лучше оформлять одним целым комитом (можно с подкомитами), чтобы по возможности протестировать различные комбинации кумулятивных хотфиксов.
    • 0
      Мы ушли от такого варианта, потому что нам приходилось делать копии конфигураций в TeamCity на каждый релизный бранч (компиляция, тесты, сборка пакета, в сумме 5-6 конфигов), к тому же если делать хотфикс в релизном бранче, есть шанс забыть сделать cherry-pick назад в master (лучше, конечно, как в вашем варианте — из master)
      • 0
        В этом случае вам все равно ничего не мешает завести ветку lastRelease и простенький build script. git reset --HARD lastRelease origin/v1.0.0.
        Я к тому, что вам повезло, если вы поддерживаете только один стабильный релиз :) Если у вас их несколько, чаще всего нужен быстрый доступ ко всем.
  • 0
    несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

    В смысле не ясен? Те коммиты, что были замержены, будут и в релизе.

    Материал частично перекликается с git-flow, но здесь описан более простой вариант.

    Ага, дополнительный странный бранч намного «проще».
    • 0
      Если вся разработка ведется в одной ветке, в которую идут активные мержи (и разработчиков много), то состав релиза зависит от момента сборки. Если build-машина собирает на каждое обновление репозитория, то у нас может в итоге получиться много разных сборок «version 1.0».
      Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
      Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.
      • +1
        В классическом примере разработка ведется в master ветке?

        У нас тоже собирается автоматически major релиз, но проблем таких с gitflow нет. Мержит один человек и билд получается только один.

        Вообще, кажется что у вас абсолютно тот же git flow, только в оригинале отдельная ветка используется для разработки (develop), а у вас для релиза (release).
        • 0
          Да, в master. Если мержит один человек, проблемы нет. Мы используем gerrit, замержить может любой ревьюер после прохождения ревью.
          Кстати, про git flow мы узнали не так давно — как раз при подготовке статьи, думаем его попробовать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.