Лучшая стратегия управления релизами?
Я работаю в компании, которая делает веб-инструмент. В рамках моей работы мне была поручена задача разработки выпуска этого продукта (чего я никогда раньше не делал). Я настроил следующую систему, используя SVN(Извините, мы не можем использовать другой репозиторий, прежде чем кто-то предложит перейти на GIT или perforce или один из множества других вариантов!)
Магистраль-это то, что всегда находится на производственных серверах. Есть 2 отделения, открытые в любой момент времени 1) отпуск обслуживания. Это выпускается каждую среду 2) ветка спринта. Это выпущено еженедельно(в среду с этой неделей maint branch)
Перед выпуском я сливаю ветви этой недели в ствол.
Я обнаружил, что при запуске svn merge, он обычно создает массу проблем, когда он сливается. Таким образом, мы перешли на ручное собрание слияния раз в неделю, которое занимает от 10 минут до 1 часа, где я буквально обыгрываю 2 каталога в своей системе и спрашиваю каждого разработчика: "было ли это ваши изменения? какую версию этого кода мы должны сохранить?"
Эта система определенно не идеальна.Может ли кто-нибудь предложить что-нибудь получше?
4 ответа:
Во-первых, извините! Я не завидую вашему положению.
Я работал в Международном банке, занимаясь редизайном веб-сайтов для Федерального закона О картах. Та же ситуация, что и у вас, только, скорее всего, в гораздо большем масштабе. У нас было 3 человека, которые ничего не делали, кроме управления релизами по очень похожему графику. Единственное, что сделало его работоспособным (в течение нескольких недель я работал с парой сотен файлов одновременно), был тот факт, что разработчики слились в trunk, а затем trunk был развернут в производство в виде копии....мы этого не сделали. проверьте непосредственно в производстве. Итак, с точки зрения релиза вы можете помочь разработчикам corral проверить свою работу (в чем разница между "обновлением" или ответом "это правильная версия?"действительно), но тогда вы не слепо выбираете, какие обновления должны идти в прямом эфире, что кажется серьезной проблемой. Конечно, разработчики могут немного пожаловаться, но, будучи в таком положении, это действительно не так уж плохо. И если вы сделаете себя доступным, чтобы ответить на любые вопросы это может всплыть, все должно быть в порядке. Он работал для 1200 с лишним разработчиков, которые работали в 4 местах по всей стране.Еще одна вещь, которую это дает вам, - это время для тестирования. Если код не объединяется до того, как он начнет работать, как он может быть протестирован в контексте более крупной системы? Я очень надеюсь, что ответ не в том, что его не проверяют!
Ваша ветвьtrunk должна содержать весь последний код разработки, который включает в себя новые и непроверенные функции и любой код из других ветвей. Очень важно, чтобы весь код был объединен в эту ветвь.
Когда вы будете готовы (или думаете, что готовы) к тестированию, создайте стабильную ветвь от вашей ветви ствола. Используйте эту ветку только для тестирования и исправления ошибок. Не добавляйте в приложение никаких новых функций или улучшений, иначе оно может быть изменено. дестабилизируйте существующий код. Не забудьте объединить изменения, внесенные в этой ветви, в вашу магистральную ветвь.
Когда вы будете готовы к выпуску (ваше тестирование завершено), создайте ветвь release от вашей стабильной ветви. Это ветвь, которую вы выпускаете в производство и поддерживаете/поддерживаете, если в производстве обнаружены ошибки/проблемы. Как и в случае со стабильной ветвью, не добавляйте к ней ничего нового. Эта ветвь обычно помечается для того, чтобы идентифицировать ее в производстве. Не забывайте об этом. объедините изменения, внесенные в этой ветви, в стабильную ветвь, чтобы другие ветви выпуска, созданные из стабильной ветви, получили выгоду от любых исправленных ошибок.
Иерархия ветвей будет выглядеть следующим образом:
trunk |-- stable 1.0 |-- release 1.0 |-- release 1.1 |-- stable 2.0 |-- release 2.0Используя эту иерархию, ваша команда разработчиков может свободно развиваться в вашей магистральной ветви, в то время как ветви stable и release позволяют поддерживать текущую и предыдущие версии вашего приложения.
Утверждение "в любой момент времени открыто 2 филиала" вызывает у меня беспокойство. По крайней мере, в моей практике ветви создаются для стабилизации перед релизом или для исправления ошибок, и они обычно недолговечны.
Мой вопрос - для чего вы используете багажник? Это не должно быть то, что находится в производстве, скорее производство должно быть запущено помеченной (следовательно, выпущенной) версией.
Насколько я вижу, ваши проблемы слияния вызваны самим собой.
Идеальной стратегией ветвления для этого сценария является. Последние разработки в trunk и для каждого выпуска вырезают из него ветвь и называют ее ветвью выпуска maintainance. Однако в вашем случае релиз maintainance происходит в багажнике. Последнее развитие происходит в отрасли.
Оставим стратегию ветвления в стороне. Вот несколько предложений по улучшению сложившейся ситуации.
Поскольку вы говорите, что изменения, связанные с производством, сначала происходят в багажнике, я предполагаю, что это будет минимальный. Так почему бы вам не объединить каждое изменение, связанное с производством, в эти две другие открытые ветви на регулярной основе. Я бы сказал, один раз в день, он также может быть более частым или менее частым. вы сможете лучше судить. Это также дало бы разработчикам больше информации об изменениях, происходящих в производстве, уменьшая конфликт. Кроме того, если возникнет конфликт, это будет обработано самими разработчиками в ветке.
Вы можете придумать какой-нибудь структуры
Должны быть в состоянии определить, какие ветви, которые требуют фиксации, сделанные в стволе.
Может быть скрипт post commit hook, который проверит, находится ли фиксация в транке, и сразу же выполнит слияние svn с веткой и посмотрит, есть ли конфликт.
Если слияние прошло успешно, зафиксируйте изменения. В противном случае отправьте информацию вам и соответствующему разработчику, который ее зафиксировал(это зависит от того, как вы хотели бы заниматься этим).