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

Question

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

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

Перед выпуском я объединяю эти недели в ствол.

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Насколько я понимаю, ваши проблемы слияния вызваны самостоятельно.

Answer 3

Прежде всего, извините! Я не завидую вашей позиции.

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

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

Answer 4

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

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

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

2. Вы можете придумать какую-то платформу

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

   • Может существовать сценарий перехвата после фиксации, который проверит, находится ли коммит в транке, и немедленно выполнит слияние SVN с веткой и выяснит, является ли их конфликтом.

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