Мне очень нравится рабочий процесс "github flow", описанный Скоттом Чаконом: http://scottchacon.com/2011/08/31/github-flow.html
Он описывает, почему github не использует рабочий процесс git flow, описанный Винсентом Дриссеном (http://nvie.com/posts/a-successful-git-branching-model/), и мы не используем его по тем же причинам, где наиболее важные причины заключаются в том, что он плохо работает с запросами на вытягивание, и он не подходит для разработки веб-сайтов, если у вас нет «официально выпущенных версий программного продукта», но вы постоянно улучшаете веб-сайт.
Мы развиваем большое онлайн-сообщество в небольшой команде с большим количеством старого устаревшего кода (некоторый код старше 10 лет) с плохим тестовым покрытием. Мы используем тот же рабочий процесс, что и github, в настоящее время мы используем ветки функций для разработки и используем запросы на вытягивание, чтобы интегрировать их в главную ветку, проводить коллегиальные обзоры, запрашивать отзывы и т. Д. Когда функция была завершена и одобрена другими, она слился с мастером. Несколько раз в неделю мы отправляем master в промежуточную среду, которую используют наши тестировщики, а также пользователи бета-версии. Мы стараемся выпускать основную ветку для всеобщего ознакомления каждые две недели, поэтому каждая объединяемая функциональная ветвь должна быть протестирована достаточно хорошо, а «более рискованные функциональные ветки» не объединяются в последние несколько дней, пока не будет выпущен общедоступный выпуск.
Это не идеальный рабочий процесс, потому что, когда слияние «рискованных функций» в master запускается снова, мы больше не можем использовать master для публичного развертывания исправлений.
Github использует непрерывную доставку для развертывания, что для нас не вариант, нам действительно нужны люди для тестирования функции, прежде чем мы сможем опубликовать ее.
Запрос на перенос можно объединить только в одну ветку. Так что это простой рабочий процесс на github с одной длинной ветвью, которая является master. Возможно, нам следует выпускать не каждые две недели, а выпускать пулреквесты, когда они объединяются в мастер? Но таким образом это сложно тестировать, мы могли бы запустить модульные тесты, которые у нас есть в функциональной ветке, прежде чем она будет объединена, и мы могли бы развернуть ветку для промежуточной подготовки для бета-тестеров, но это не всегда так просто, иногда вам нужно сделать база данных изменяется вручную (мы не можем сделать это автоматически, это слишком рискованно, потому что наш промежуточный сервер для бета-тестеров использует производственную базу данных), поэтому вам придется подождать, пока это сделают администраторы. И более серьезная проблема заключается в том, что если вы выпускаете только функциональные ветки для бета-пользователей, они не интегрированы, они будут видеть новые функции, а функции удаляются, возможно, несколько раз в день. Нельзя сказать, что вы не можете запускать интеграционные тесты или вы запускали их очень поздно перед выпуском, когда функциональная ветка просто объединяется в master ...
С другой стороны, если мы используем 2 долго работающие ветки, такие как разработка и мастер, как описано в git-flow, мы можем решить проблему исправления, мы могли бы использовать пул-реквесты для слияния функциональных веток для разработки, мы могли бы использовать пул-реквест для ветвь выпуска для слияния последних изменений с основным, но мы не можем слить обратно изменения для разработки с использованием рабочего процесса запроса на вытягивание.
Как вы можете видеть в статье о потоке github (№ 6 - развертывание сразу после проверки), инженеры github могут развертывать не только в производственной, но и в промежуточной среде. И это могут делать не только инженеры, но и саппорт, и дизайнеры. Но как это работает только с одной интеграционной веткой? Вам не нужна промежуточная среда, если последний запрос на перенос все равно будет запущен в производство через несколько часов или минут. Иногда кажется, что они развертывают ветки функций для промежуточной обработки, что имеет смысл, но они не интегрированы, поэтому то, что я описал выше, произойдет, вы увидите, как функции появляются и исчезают в вашей промежуточной среде, даже если они объединяют изменения из мастера перед развертыванием функции. -ответвление к постановке (как вы думаете, это будет хорошая идея?). Или имеет смысл иметь несколько промежуточных сред, по одной для каждой функциональной ветки? Но в этом случае вы снова теряете преимущества от непрерывной интеграции. И, как уже было сказано, я не думаю, что вы сможете сделать это в среде бета-тестирования.
Я вижу проблемы в обоих рабочих процессах, git flow и github flow, мне больше нравится github flow, но это кажется трудным, если у вас нет хорошего тестового покрытия и вам нужно больше тестирования людьми.
Итак, как я могу интегрировать и тестировать ветки функций, когда они нуждаются в дополнительном тестировании людьми (тестировщиками качества и бета-тестирования)?
