Лучшая стратегия управления выпуском?

Question

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

Trunk - это то, что находится на производственных серверах в все время В любой момент времени открыты 2 филиала 1) Техническое обслуживание. Это выпущено каждую среду 2) Спринт-ветвь. Это выпущено еженедельно (в среду с филиалом этой недели)

До освобождения я сливаю ветви недель в багажник.

Я обнаружил, что при запуске svn merge он обычно создает массу проблем при слиянии. Таким образом, мы переключились на ручное собрание по объединению раз в неделю, которое занимает от 10 минут до 1 часа, где я буквально выигрываю 2 каталога в своей системе и спрашиваю каждого разработчика: «Это было ваше изменение?», Какая версия этого кода должна нам держать?"

Эта система определенно НЕ идеальна.

Может кто-нибудь предложить что-то лучшее?

Answer 1

Прежде всего, ИЗВИНИТЕ! Я не завидую вашей позиции.

Я работал в международном банке, создавая веб-редизайн для Федерального закона о карточке. Такая же ситуация, как и вы, вероятна только в гораздо большем масштабе. У нас было 3 человека, которые ничего не делали, кроме управления релизами, в очень похожем графике. То, что сделало его удачным (за несколько недель я работал с несколькими сотнями файлов за раз), был тот факт, что разработчики слились с багажником, затем багажник был развернут на производство в качестве копии ... мы не прямо в производство. Итак, с точки зрения выпуска, вы можете помочь разработчикам corral, чтобы их работа была проверена (в чем разница между выполнением «обновления» или ответом «действительно ли это правильная версия?»). Но тогда вы не слепо выбираете, какие обновления должны идти вживую, что кажется серьезной проблемой. Конечно, разработчики могут немного пожаловаться, но, находясь в этой позиции, это действительно не так уж плохо. И если вы позволите себе ответить на любые вопросы, которые могут возникнуть, все должно быть в порядке. Он работал на 1200 разработчиков, которые мы работали в четырех местах по всей стране.

Другое, что вы покупаете, это время для проверки. Если код не сливается, прежде чем он начнет жить, как его можно протестировать в контексте более крупной системы? Я надеюсь, что ответ не в том, что он не тестируется!

Answer 2

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

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

Ваши проблемы с слиянием наносятся, насколько я могу судить.

Answer 3

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

Сохранение стратегии разветвления в сторону. Вот несколько советов по улучшению текущей ситуации.

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

2. Вы можете думать, придумывать какие-то рамки

   • Должны быть в состоянии определить, какие ветви которых требует коммиты, сделанные в багажнике.

   • Возможно, существует сценарий фиксации фиксации сообщения, который будет проверять, является ли коммит в trunk, и слияние svn сразу с веткой и посмотреть, является ли конфликт конфликтом.

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

Answer 4

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

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

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

Иерархия филиала будет выглядеть следующим образом:

trunk 
|-- stable 1.0 
    |-- release 1.0 
    |-- release 1.1 
|-- stable 2.0 
    |-- release 2.0 

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