Что произойдет, если функция, включенная в разработку, будет отложена руководством?

53

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

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

Как мы могли избежать этой проблемы?

project-management git gitflow

— Стив
источник

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

— Малавос

74

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

Другой вариант - сделать возвратный коммит, который отменяет слияние функций, чтобы он больше не разрабатывался. Можно создать новую ветвь, которая отменяет возврат, и оставить ее в ожидании слияния позже. Если вы используете Github Pull-запросы, вы можете легко сделать это с помощью кнопки «Revert Merge» в объединенном Pull-запросе.

— Daenyth
источник

9

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

16

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

— Алан Шутко

4

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

— Док Браун

3

У нас есть функции, которые находятся в разработке более 6 месяцев и скрыты Feature Toggling, как назвал это Док Браун. Это также позволяет нам тестировать функцию (или ее отсутствие) в непроизводственной среде. Иногда эти функции добавляют к существующим функциям, и в этом случае у нас должны быть модульные тесты как для старого, так и для нового набора функций. Каждый модульный тест просто устанавливает флаг на то, что ему нужно для текущего теста.

— ps2goat

25

Как мы могли избежать этой проблемы?

С точки зрения процесса, выяснить:

Кто принял решение начать эту работу?
Почему решение о выпуске этой функции изменилось?
- Пропущенные ожидания?
- Непонимание?
- Недостаточная поддержка бизнеса?
- Нет участия клиента?

Скорее всего, по пути произошли перепады в общении. Это важно иметь, потому что когда это не работает, ваш процесс (ы) разработки будет основан на ложном и неправильном понимании бизнес-требований.

— enderland
источник

9

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

— Барт ван Инген Шенау

14

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

— gbjbaanb

11

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

— Стив Джессоп

2

Я полностью согласен, это провал управления, а не разработчик.

— durron597

3

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

— gbjbaanb

19

Забудьте на мгновение проблему с вашим руководством и представьте, что у вас уже есть «функция автоматической регистрации» в вашем последнем производственном выпуске, глубоко интегрированная в вашу кодовую базу. Теперь вы получаете новое требование добавить «выключение» для «автоматической регистрации». Как бы вы справились с этим в вашем рабочем процессе Git?

Я полагаю, вы бы объявили «отключение автоматической регистрации по конфигурации» просто как дополнительную функцию (это просто форма переключения функций ), поэтому она должна плавно интегрироваться в ваш рабочий процесс. Вы можете оценить усилия, если хотите, можете использовать для этого ветку функций (или нет, если вы не используете ветки функций для таких проблем). И вы определенно можете использовать описанный вами поток «merge dev -> test -> master».

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

— Док Браун
источник

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

— Gusdor

@Gusdor: см. Мое редактирование.

— Док Браун

1

Это именно та проблема, которая у меня возникла с Gitflow и GitHub, и кажется, что с веб-приложениями это происходит часто - или, скорее, как норма. Похоже, вы бы решили эту проблему задним числом (упомянуто выше) или упреждающим образом (пример ниже).

Я создал «ветки связки» в дополнение к стандартным веткам gitflow. Пакет состоит из всех функций, которые готовы для UAT / QA. Список функций uat / qa создан. Они объединяются во временный пакет, и этот пакет развертывается в uat / qa. Любое исправление ошибки происходит в исходной ветви функций, и это возвращается обратно в пакет и развертывается. Это отделяет грядущий выпуск, а также позволяет тестировать эти функции вместе, прежде чем они найдут путь к ветви разработки. Те ветки, которые одобрены, получают запрос на разработку в соответствии с процессом gitflow. Готовые тестовые функции могут быть добавлены или удалены из временной ветви пакета и повторно развернуты.

Это позволяет мастеру всегда отражать состояние готовности к производству (можно автоматизировать с помощью крючка)
Разработка всегда отражает последнюю поставленную (и протестированную) версию следующего кандидата

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

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

— Дэвид Латти
источник