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

Question

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

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

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

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

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

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

Спасибо.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Пока не пробовал ...

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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