Тенденция «развивающейся» отрасли уходит

В последнее время я заметил кое-что популярное на GitHub, в котором нет developветок. И на самом деле, руководство GitHub Flow также не упоминает об этом. Насколько я понимаю, masterвсегда должен быть абсолютно стабильным и отражать производство. Если разработчики работают над ветвями компонентов, а затем объединяют их, masterкогда они сделаны, это означает, что есть период времени, когда функции / исправления объединяются, masterи masterветвь фактически новее производственной.

Разве не имеет смысла, чтобы команда создавала ветки функций / исправлений develop, сливалась с ними, а затем, когда следующая версия полностью готова к выпуску, developобъединяется masterи создается тег? Представьте, что люди объединяются master, и в процессе работы сообщается об ошибке, которую становится трудно исправить, поскольку masterбаза кода филиала значительно изменилась. Затем разработчики просто должны сказать пользователю, чтобы он подождал до следующей версии, чтобы увидеть, что проблема решена.

РЕДАКТИРОВАТЬ: Этот вопрос отличается от «ветвиться или не ветвиться». В нем конкретно рассматриваются люди, отказывающиеся от использования ветки разработки, и причины, связанные с этим, поскольку это долгое время рекламировалось как лучшая практика.

Это происходит из мышления CI, где есть интеграция несколько раз в день.

Есть плюсы и минусы обоих.

В нашей команде мы также отказались от развивающейся ветки, так как чувствовали, что она не дает никаких дополнительных преимуществ, но имеет несколько недостатков. Мы настроили наше программное обеспечение CI (Teamcity), чтобы компенсировать недостатки:

1. Разрешить развертывание определенного коммита. Другими словами: мы не разворачиваем ветку. Мы развернем коммит.
2. Мы можем развернуть либо master, либо ветки, начиная с исправления / префикса.

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

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

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

Например, представьте, что вы пишете программное обеспечение, которое является прошивкой для автомобилей. Это ... нетривиально исправить, и, скорее всего, в любом выпуске будет полный набор не-CI / интеграционных тестов, выполняемых на реальном оборудовании.

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

Веб-приложения или другое легко обновляемое программное обеспечение не имеют этого ограничения.

Однако обратите внимание, что:

• Многие (большинство?) Проекты на github не имеют такого рода ограничений
• Главный «мастер» служит той же цели
• Рабочий процесс «сделай пиар против хозяина» гораздо более универсален, чем «сделай пиар против ветки, которую вы не знаете сразу в этом репо»

Есть две философии, которые я видел в проектах, и я думаю, что выбор - дело вкуса:

1. Обозначьте «master» как выпуск продукта и развивайтесь в ветке «Develop».

2. Разработайте в 'master' и создайте ветку с другим именем для стабильных производственных выпусков. Это имеет еще больший смысл, если в вашем проекте одновременно несколько веток релиза (например, текущим предпочтительным является Release-1.8, но вы все еще поддерживает Release-1.7).

Оба являются общими подходами, и имеют свои плюсы и минусы.

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

Если в производственном процессе обнаружена критическая ошибка в момент, когда мастер не может быть выпущен, то достаточно просто извлечь тег и начать с него новую ветку «hotfixes-for-release-1.2.0». Но это должно быть довольно редко.

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

Если разработчики работают над ветвями компонентов, а затем объединяют их с master, когда они закончили, это означает, что есть период времени, когда функции / исправления объединяются, masterи masterветвь фактически новее производственной.

...

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

Это не Github Flow.

Это процесс развертывания / объединения Github Flow, согласно вашей ссылке:

развертывание

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

сливаться

Теперь, когда ваши изменения были проверены в рабочей среде, пришло время объединить ваш код с главной веткой.

(Акцент мой)

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

Проблема, которую я вижу, состоит в том, что развертывание / слияние потока Git / Hub предполагает, что одна функция разрабатывается / тестируется / объединяется / развертывается за один раз - и часто, по моему опыту, это не так. Если мы объединяем функцию за один раз, у проблем с регрессией больше шансов - она ​​обнаруживается только после того, как функции объединены в мастер и, возможно, в производство.

Должен быть способ протестировать несколько функций, объединить несколько функций и развернуть их. Я использовал «ветку связки» (ветку, созданную из master с объединенными в нее тестовыми готовыми ветвями функций), которая развертывается в qa / uat. Исправления в течение времени uat происходят только в ветви функций, и они повторно объединяются с ветвью пакета. После утверждения подраздела ветви пакета только те утвержденные функции в комплекте получают запрос на извлечение для мастера - и цикл продолжается.

Я использую это с Gitflow, но размышляю, чтобы использовать его для потока GitHub. Многие функции QA / UAT, возникающие одновременно, кажутся важными. Еще одна проблема, связанная с потоком GitHub, заключается в том, что он принимает всех разработчиков sr, и это не всегда так.

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

Другая проблема заключается в том, что процесс извлечения запроса происходит в конце перед слиянием с master; однако иногда требуется выполнить проверку кода до тестирования бизнес-качества, а значит, задолго до слияния.