Управление Выпусками — Как Избавиться От Ветки Разработки Для Упрощения Потока Git

В постоянно развивающемся веб-проекте (не продукте) мы в настоящее время имеем следующую стратегию ветвления, примерно основанную на поток git:

• ветка разработки: последняя рабочая версия
• основная ветка: версия, которая будет выпущена/выпущенная версия
• ветки функций: функции в разработке
• ветки исправлений: срочные исправления ошибок в выпущенной версии

Владелец доступен только для чтения, обновляется посредством запросов на извлечение из развивать или ветки исправлений. Каждое обновление приводит к созданию и развертыванию кандидата на выпуск в промежуточной системе. Кандидаты на выпуск развертываются в производство после утверждения вручную.

Функциональные ветки создаются на основе развиватьили из последнего коммита, который был объединен с мастером. Запрос на извлечение из функциональной ветки для разработки создается и развертывается в бесплатной системе тестирования, где выполняются интеграционные и приемочные тесты (автоматические и ручные). После успешного тестирования и проверки PR объединяется и становится частью следующего выпуска (т. е. объединяется из разработки в мастер-версию).

Моя цель

Я хотел бы упростить это и избавиться от ветки разработки. Ветка разработки имеет в основном исторические причины, и поскольку это всегда успешно протестированная версия, я думаю, нет необходимости хранить ее отдельно от основной. Его удаление также упростит процесс выпуска, поскольку больше не требуется никакого дополнительного слияния.

У меня есть следующие ограничения:

• выпуски запланированы и не должны быть полностью автоматизированы.
• хотя ветки функций обычно недолговечны, некоторые остаются неслитыми в течение нескольких недель (например, редизайн), но их также необходимо протестировать (в настоящее время открыты запросы на включение для разработки)
• иногда одну функцию следует выпустить за пределами обычного выпуска, фактически превращая ее в исправление. Используя текущую стратегию, я могу перебазировать ветку функций и объединить ее непосредственно с основной.
• бывает и так, что нам нужно придержать функции после неудачных приемочных испытаний с внешними системами на стадии разработки.

Где я не уверен насчет перехода:

• в настоящее время я создаю запросы на включение для тестирования и коммиты слияния для выпусков. Могу ли я объединить это?
• как быть с исправлениями, когда мастер опережает последний релиз. Должен ли я создавать и развертывать выпуски непосредственно из веток исправлений?
• Есть ли разумный способ справиться с функциями, которые следует исключить из выпуска после того, как они уже были объединены? Является ли отдельная ветка разработки преимуществом в таких случаях? В большинстве случаев я все равно откатываю и откатываю коммиты вручную.

#git #release-management #builds #branch

ИМХО, проблемы, с которыми вы сталкиваетесь, являются лишь побочным эффектом плохой стратегии ветвей, с которой вы начали: вы эффективно продвигаете новую разработку на git revert (i.e. what converges towards the будущее производственный код) через тот текущий производственный код на master . This leads to contradicting requirements and problems since typicaly the future code diverges from the current one:

• новая разработка дестабилизирует производство – после слияния наблюдается регресс master into master
• стабилизация производства замедляет дальнейшее развитие - нужно стабилизировать master to make it good enough for merging into develop

падение develop won't help (much) - you're not eliminating the problem, you're just transferring the master - конкретная часть проблемы в develop .

Лучшим подходом было бы перенести производство позади текущая/будущая разработка, чтобы предотвратить вмешательство в разработку будущих выпусков, как показано на этом изображении из Какова ваша модель ветвления?:

Обратите внимание, что я имею в виду только ветки выпуска на изображении выше, а не то, что происходит в багажнике.

Как это будет работать для вас:

• тот master branch dissapears, as you wished, absorbed into master
• тот develop branch is your trunk, this is where development happens with no speed restrictions (it's никогда объединены в производство).
• производство представляет собой одно или несколько master branches pulled from a develop этикетка/тег считается достаточно близким к качеству производства (при необходимости краткий список оставшихся задач можно найти в этой ветке). Эти ветки могут получать только прямые исправления и/или выборочные исправления от master , they are никогда слился с releaseX or other branches
• исправления — это прямые фиксации в master branches

Если исправление применимо только к производственной версии, но не к release it is directly committed to the develop ветвь. Если это применимо к обоим, оно обычно стремится к master first and cherry-picked/double-committed to the release филиал тоже.

Теперь посмотрим, что происходит master (which is past the point where the current release ветка снята), у вас есть 2 варианта:

• продолжайте создавать ветки функций, как и сегодня, за исключением того, что они будут основаны на master , not release . Преобразование их в исправления остается возможным — вам просто нужно будет перебазировать их в соответствующие master branch instead of release
• переключиться на непрерывную интеграцию и воспользоваться ее преимуществами (можно сделать в любой момент), в том числе постепенно — постепенно вытягивать все меньше и меньше функциональных ветвей.

Если вам нравится этот подход, вот как вы доберетесь туда, где вы находитесь сегодня:

• установить стратегию именования выпусков:
  • у вас не может быть текущей ветки выпуска с тем же именем
  • вы не можете (на самом деле не должны) перебазировать или синхронизировать ветку производственного выпуска
• потянуть master branch from master немедленно, следуя этой стратегии именования
• остановить коммиты от входа в master , they'll be soon going straight to release .
• слить master into master
• поручить разработчикам перебазировать свои рабочие области на develop instead of master .
• открыть develop for commits
• удалить develop if you desire (or leave it permanently locked/read-only for reference)

Допустим, вы удаляете главную ветку (вы можете переименовать ее в master, чтобы потом запутать вашу команду) и просто используете теги для выпусков либо в ветках разработки, либо в ветках исправлений. Вы вынесли ветку, но разница всего лишь в изменении синтаксиса. Изменения ради изменений.

Теперь предположим, что вы действительно прекращаете разработку, сохраняя заблокированную главную ветку. Что произойдет, так это то, что интеграция кода замедлится, он будет дольше жить разделенным по ветвям функций, особенно ближе к датам выпуска. Это каждый раз будет увеличивать сложность слияния и замедлять процесс.

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

Вы уже создаете и тестируете код для каждой ветки запроса на включение и исправления. Это означает, что в совокупности сумма всех ветвей, ожидающих пул-реквеста, представляет собой ваш виртуальный master branch.

Вы можете создать систему, когда в тестовой среде несколько пул-реквестов выбираются во временную ветку, которая не публикуется в основном репозитории. Эта ветка используется для интеграции тестовой среды, включающей develop and several additional pull-requests, but once the testing is done, this branch is no longer available anywhere.

Когда вы создаете релиз из master , you would usually create a tag on that release. Later hotfixes can use that tag to create a new hotfix branch from which a deployment will be made, even though the edge of develop уже впереди. В этой ветке исправлений вы, вероятно, также пометите второстепенный выпуск и убедитесь, что изменения были объединены в master .

Удалить объединенные функции из релиза с помощью git довольно сложно. Лучшим механизмом для этого было бы использовать develop on the merge commit. But that makes it almost impossible to get these features/changes back, and history becomes all muddled.

Гораздо лучший способ справиться с разделением развертывания кода и выпуска функций — флаги функций. Если ваши разработчики могут скрыть свои функции за некоторыми условиями в самом коде, вы можете развернуть их код, но отключить эту функцию. Это отдельная тема, но информации по этому поводу существует много (в том числе вопросы и ответы на devops.SE).

Что ж, @dan-cornilescu хорошо сказал это для вашей конкретной проблемы, но более общий случай разработки на основе магистральной линии (упомянутый в «Непрерывной доставке», «Бережливом предприятии» и «Руководстве DevOps») приведен здесь: https://trunkbaseddevelopment.com/