Разработчики заблокированы из-за ожидания слияния кода из другой ветки с помощью GitFlow


17

Наша команда только что переключилась с FogBugz & Kiln / Mercurial на Jira & Stash / Git. Мы используем модель Git Flow для ветвления, добавляя ответвления подзадач от ответвлений объектов (относящихся к подзадачам Jira функций Jira). Мы используем Stash для назначения рецензента при создании запроса на извлечение для слияния обратно с родительской ветвью (обычно разрабатываются, но для подзадач обратно в ветвь функций).

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

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

Я знаю, что это не обязательно проблема Git - это связано с работой над взаимозависимым кодом в нескольких ветвях в сочетании с нашим собственным рабочим процессом и культурой. Если бы у нас не было строгой политики проверки кода для разработки (истинная ветвь интеграции), тогда разработчик 1 мог бы объединиться, чтобы разработать для разработчика 2. Еще одним осложнением является то, что нам также необходимо провести некоторое предварительное тестирование в рамках процесса проверки кода, прежде чем передавать эту функцию в QA. Это означает, что даже если внешний разработчик 1 извлекает непосредственно из ветви внутреннего разработчика 2, когда они если конечный разработчик 2 завершает работу, а его / ее запрос на извлечение в течение недели находится на рассмотрении кода, то интерфейсный разработчик 2 технически не может создать свой запрос на извлечение / просмотр кода, поскольку его / ее рецензент кода не может тест, потому что внутренний разработчик 2 '

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

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


Просто проверка - выполняется ли проверка кода при слиянии задачи с функцией? а нет обзора кода по слиянию функций для разработки?

По-разному. У нас есть практическое правило, согласно которому ни один случай Jira, соответствующий ветви, в которую мы непосредственно проверяем код, и которая не выступает в качестве «зонтичного» случая в смысле иерархии, занимает более 2 дней. Таким образом, если для случая с функциональностью требуется <= 2 дня, будет проведен анализ кода для объединения этой функции в разработку. Если есть подзадачи, после того как все они объединены в свой функциональный билет, кто-то делает запрос на извлечение для объединения этой функциональной ветви в разработку, но не на том же уровне проверки кода, поскольку все подзадачи уже прошли этот процесс.
fogwolf

Ответы:


11

Проблема также может заключаться в слишком жестком разделении задач между серверной и интерфейсной разработкой.

Если разработчику внешнего интерфейса требуется новый API, не возможно ли ему или ей создать фиктивный API на бэкэнде (возвращая всегда одно и то же значение, например) для проверки макета? Затем зафиксируйте эту частичную реализацию с заглушкой, и во второй раз серверный разработчик реализует реальную функцию.

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


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

6
Хотя это не является частью вашего процесса разработки, не является ли это дополнительными затратами, чем то, что два разработчика вертят свои пальцы в течение трех дней, ожидая, пока кто-то другой сделает свой код? У вас есть 8 часов потраченного впустую времени разработчика на большого пальца. Сравните это со временем, которое требуется, чтобы заглушить бэкэнд-зависимости.
Грег Бургхардт

5

Ваша проблема: ветвь Developer A от Master, ветвь Developer B от Master, обе работают над тесно связанными функциями, и неизбежный факт, что слияния с веткой Master трудны из-за неизбежных конфликтов, является тем, что сдерживает всех.

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


0

Если разработчик 1 работает над функцией A, а разработчик 2 завершил работу над функцией B, которая зависит от функции A, то пути к этому нет - объединение функции B приостановлено. Вы не можете протестировать его без функции A, и пока нет смысла просматривать его, поскольку дальнейший прогресс в функции A может привести к изменениям в функции B.

Это, однако, не означает, что разработчик 2 приостановлен! Разработчик 2 может начать работу с функцией C и вернуться к циклу исправления и проверки функции B после завершения функции A. Я знаю , что переключение контекста не является оптимальным, но с того времени , он будет принимать к полному признаку А, вероятно , измеряются в дни , это не что плохо (вы не вытягивать их из «Зоны» на 15 минут боковой задачу)


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

0

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

В случае, когда разработчик ожидает функции от другого разработчика, есть ли способ, чтобы часть работы первых разработчиков могла пройти проверку и интеграцию до полной возможности, чтобы освободить блок?

Существуют ли способы разбить функции на более мелкие единицы работы, чтобы поддерживать цикл интеграции?

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


Это мои главные надежды. Я не думаю, что мы можем устранить эту проблему, но, освоившись с новым рабочим процессом, я надеюсь, что мы сможем лучше планировать и разбивать нашу работу совместно в рамках этой новой системы, чтобы минимизировать проблему. Я просто проверял, сталкивался ли кто-нибудь с чем-то подобным, и имел ли он что-нибудь в отношении процесса или связанное с используемой нами моделью ветвления, которая могла бы помочь. Благодарю.
fogwolf
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.