Сроки разблокировки

Question

Часть команды работает над следующим выпуском/спринтом, а остальные работают над тестированием и исправлением ошибок предыдущего спринта перед выпуском на производство.

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

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

Любые мнения или предложения? Благодаря

Примечание:

Это было хуже, проблема в прошлом, потому что мы использовали TortoiseSVN 1.6 с 1.4 репо, который предотвратил GUI делать ответвление/слияния операций. Поэтому я устранил это препятствие, обновив репо. Члены команды должны легко слиться.

Answer 1

Еще один момент для рассмотрения:

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

С другой стороны, новая релизная работа идет по TRUNK, и TRUNK может быть зарезервирован, чтобы всегда представлять то, что находится в «текущей» или «производственной» среде. Если вы хотите отменить исправления, сделанные для предыдущих выпусков, в текущую версию, вы можете объединиться с веткой bugfix в TRUNK.

Эта модель может быть повторена и после следующего тега выпуска.

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

HTH.

Answer 2

Я очень рекомендую Git/Mercurial для подобных проблем. :)

Но поскольку я знаю, что это не вариант, я просто скажу, что на эти проблемы не существует 100% отличного ответа. В общем, я предпочитаю не разветвляться до тех пор, пока это возможно в самом конце процесса, поскольку ветвление и слияние с CVS/SVN имеют тенденцию быть тяжеловесными процессами. Чем дольше вы можете отложить процесс перехода, тем лучше вы во многом. Но, как знает команда, работающая над новыми функциями, это может продолжаться так долго ... в какой-то момент стоимость задержки новых функций перевешивает преимущества отсрочки слияния.

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

Отделение как можно скорее.