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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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