Как вы справляетесь с противоречием между рефакторингом и необходимостью слияния?

Question

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

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

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

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

Но это означает, что разработчикам придется подождать некоторое время, прежде чем вносить в магистраль какие-либо изменения рефакторинга, поскольку это может нарушить последующее слияние из ветки в магистраль.А необходимость вручную переносить ошибки из ветки в магистраль — это болезненно.Мне кажется, это тормозит развитие...

Как вы справляетесь с этим напряжением?

Спасибо.

Answer 1

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

Я предпочитал позволить основному каналу работать с нормальной скоростью и не задерживаться, потому что в среде, где сроки выпуска были важны с коммерческой точки зрения, я никогда не мог утверждать, что мы должны позволить коду стабилизироваться («что, вы имеете в виду, что вы выпустил его в нестабильном состоянии?").

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

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

Я так и не нашел хорошей литературы по этой теме.Это неизбежно будет связано с вашей стратегией выпуска и соглашениями об уровне обслуживания, которые вы подписываете со своими клиентами.

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

Answer 2

Там, где я работаю, мы создаем временные, кратковременные (меньше суток — несколько недель) рабочие ветки для каждого нетривиального изменения (добавление функции или исправление ошибок).Багажник стабилен и (в идеале) потенциально может быть высвобожден в любое время;только сделанный элементы объединяются в него.Все, что было совершено из ствола, каждый день объединяется с рабочими ветками;это можно в значительной степени автоматизировать (мы используем Hudson, Ant и Subversion).(Это последний пункт, потому что, конечно, обычно лучше разрешать любые конфликты раньше, чем позже.)

На текущую модель, которую мы используем, во многом повлияла отличная статья (который я подключил раньше) Хенрика Книберга: Контроль версий для нескольких Agile-команд.

(В нашем случае две scrum-команды работают над одной кодовой базой, но я пришел к выводу, что эта модель может быть полезна даже с одной командой.)

Есть некоторые накладные расходы, связанные с дополнительными ветвлениями и слияниями, но на самом деле они не слишком велики, как только вы к этому привыкнете и освоите инструменты (например, svn merge --reintegrate это удобно).И нет, я не всегда создаю временную ветку, например.для небольших рефакторингов с низким уровнем риска (не связанных с основными элементами, над которыми сейчас ведется работа), которые можно легко выполнить с помощью одной фиксации в магистрали.

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

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

Answer 3

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

1. Непрерывная интеграция
2. Автоматизированные функциональные тесты (полагаю, вы уже учитываете модульные тесты)
3. Автоматизированная доставка

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

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

У вас, вероятно, будет два типа недоброжелателей, поскольку это подразумевает изменение некоторых давно укоренившихся практик.Во-первых, смена парадигмы непрерывной поставки кажется менеджерам противоречивой.«Разве мы не рискуем отправить серьезную ошибку?» Если вы посмотрите на дистрибуцию Linux или Windows, это именно то, что они делают:продвижение релизов для клиентов.А поскольку вы рассчитываете с помощью набора автоматических тестов, риски еще больше уменьшаются.

Далее, команда или отдел контроля качества.(Некоторые могут утверждать, что проблема в их существовании само по себе!) Обычно они относятся к автоматизации тестов с отвращением.Это означает изучение нового и иногда сложного инструмента.Здесь лучше всего проповедовать, делая это.Наша команда разработчиков начала работать над непрерывной интеграцией и одновременно писать набор функциональных тестов с помощью Селен.Когда команда QA увидела инструмент в действии, было сложно противостоять его внедрению.

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

Answer 4

Возможно, Git (или другие DVCS) лучше обрабатывают слияния с обновленным кодом благодаря тому, что они (действительно) управляют изменениями, а не просто сравнивают файлы...Как Джоэл говорит :

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

Хотя еще не пробовал...

Answer 5

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

Answer 6

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

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