Поток Git и несколько функций, ожидающих контроля качества

Последние несколько месяцев мы свободно следили за работой gitflow, но сталкивались с проблемами, связанными с длительным ожиданием QA.

Вот наш процесс:

  • разработчики разрабатывают локально на ветках функций
  • когда команда считает, что функция готова, она объединяется с dev и отправляется на сервер разработки (Codeship и rsync)
  • клиент одобряет функцию
  • функция объединена с мастером, отправлена ​​в производство

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

Однако тем временем новая функция могла быть объединена с dev и отправлена ​​на сервер разработки для утверждения. Скажем, эта вторая функция одобрена и должна быть развернута как можно скорее (конечно). Как я могу получить эту вторую функцию от разработчика, не добавляя 1-ю функцию?


git git-flow
person paulruescher    schedule 03.09.2014    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Как мне получить эту вторую функцию от dev, не добавляя 1-ю функцию?

Вы этого не сделаете.
Но как только dev объединится с master, вы можете отменить 1-ю фиксацию функции из master, чтобы записать, что первая функция еще не утверждена.

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

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

Если бы было лучше, если бы:

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

Другими словами, вы дважды объединяете ветку функции:

  • один раз в integration для официального рассмотрения клиентом и утверждения функции
  • один раз в dev со второй (и более быстрой) проверкой клиента, чтобы увидеть, работает ли функция по-прежнему так, как ожидалось (поскольку она не объединяется в той же кодовой базе, что и интегрируемая)

С dev вы возобновляете обычный процесс управления релизами (переход к prod).

person VonC    schedule 03.09.2014
comment
Однако, отменяя коммит на master, вы не рискуете дестабилизировать эту ветку? - person jub0bs; 03.09.2014
comment
@Jubobs, как материализуется эта дестабилизация? (примечание: я согласен, что это обходной путь, master не следует вмешиваться) - person VonC; 03.09.2014
comment
Может ли операция revert не вызывать конфликтов? - person jub0bs; 03.09.2014
comment
Конфликт @Jubobs при возврате? (stackoverflow.com/a/6084535/6309) или при повторном слиянии feature1? (хотя у вас есть stackoverflow.com/a/8730046/6309) - person VonC; 03.09.2014
comment
@Jubobs Я бы не назвал это дестабилизацией, но если эта проблема возникает слишком часто, то следует принять во внимание вторую часть моего ответа. - person VonC; 03.09.2014
comment
да. Понял. Спасибо. - person jub0bs; 03.09.2014
comment
в итоге мы пришли к чему-то очень похожему на идею ветки интеграции - person paulruescher; 18.10.2014

arrow_upward
1
arrow_downward

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

Мы справляемся с этим, используя Gitflow в обычном режиме и добавляя переключатели функций к нашим функциям. Таким образом, мы можем отправить новый код функции в производство, но он будет неактивен из-за переключения функций. Мы можем настроить, активна функция или нет, используя файл свойств (мы используем Togglz).

Конечно, код становится немного запутанным со всеми «если», но преимущество в том, что если функция, которая уже находится в производстве, но отключена, будет одобрена, нам просто нужно изменить свойство в файле и перезапустить приложение. и он становится активным, не нужно делать новый релиз и устанавливать его в продакшн! Кроме того, у Togglz есть функциональная консоль (которую мы еще не пробовали), которая, по-видимому, может выполнять переключение во время выполнения.

Вы можете узнать больше о переключателях функций здесь. Вы можете узнать больше о Togglz здесь и здесь.

Надеюсь, это поможет :)

person vribeiro    schedule 02.03.2020

arrow_upward
0
arrow_downward

Это недостаточно "git-flowy". Ветка разработки должна содержать только функции, получившие одобрение. Таким образом, HEAD в разработке должен содержать только код, который был протестирован и готов к выпуску в мастер/производство.
Решение вашей проблемы с помощью git-flow заключается в следующем: заканчивая работу над фичей, вы загружаете ее в ориджин (пушите фичу) и отправляете тестировщику (клиенту?). Только после утверждения он будет объединен с Develop.

Фичи должны быть независимы друг от друга, чтобы клиент мог тестировать каждую отдельно по своему расписанию(*). В потоке у вас может быть объединены хороший и плохой код, и результат теста не поможет определить источник проблемы.

*) только если это не так, или если вы хотите параллельно протестировать функцию, используйте ветку интеграции.

person isaac-fisher    schedule 22.02.2017