Лучшие практики ветвления исходного кода и жизненного цикла приложения

Мы - небольшой магазин независимых поставщиков программного обеспечения, и мы обычно отправляем новую версию наших продуктов каждый месяц. Мы используем Subversion в качестве нашего хранилища кода и Visual Studio 2010 в качестве нашей IDE. Я знаю, что многие люди защищают Mercurial и другие системы управления исходными кодами, но на данный момент я не понимаю, как мы могли бы извлечь из них пользу, но я могу ошибаться.

Наша главная проблема - как синхронизировать ветви и основной ствол.

Вот как мы делаем вещи сегодня:

1. Выпустить новую версию (автоматически создать тег в Subversion)
2. Продолжить работу над основным стволом, который выйдет в следующем месяце

И цикл повторяется каждый месяц и работает отлично. Проблема возникает, когда необходимо выпустить срочный выпуск службы. Мы не можем высвободить его из основного ствола (2), поскольку он находится в стадии интенсивной разработки и недостаточно стабилен, чтобы его можно было срочно освободить.

В таком случае мы делаем следующее:

1. Создайте ветку из тега, который мы создали на шаге (1)
2. Исправлена ​​ошибка
3. Тест и выпуск
4. Вставьте изменения обратно в основной ствол (если применимо)

Наша самая большая проблема - объединение этих двух (ветвь с главной). В большинстве случаев мы не можем полагаться на автоматическое объединение, потому что, например:

• много изменений было внесено в основной багажник
• объединение сложных файлов (таких как файлы Visual Studio XML и т. д.) работает не очень хорошо
• другой разработчик / команда внесла изменения, которые вы не понимаете, и вы не можете просто объединить их

Так что, по вашему мнению, лучше всего поддерживать синхронизацию этих двух разных версий (отраслевой и основной). Чем ты занимаешься?

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

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

Если должно произойти серьезное архитектурное изменение, оно должно произойти в его собственной ветви, а затем снова объединиться с основным после того, как будет полностью протестировано и «стабильно» (в пределах разумного). Это может быть болезненным и сложным, но это также должно быть редко. Если у вас есть хорошие методы тестирования, то риск минимизируется.

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

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

Я склонен смотреть на это с противоположной стороны:

• Магистраль всегда должна быть готовым к использованию кодом (то есть после вашего первого первоначального выпуска).
• Должна быть ветка типа разработки, которая работает параллельно транку, где происходит ваша ежемесячная разработка. Каждый месяц, когда дело доходит до времени выпуска, это объединяется в транк, тестируется, а затем выпускается.
• После этого можно легко вносить исправления в свой ствол и регистрировать их, а также всегда успешно развертывать. Затем сделайте исправление из исправления и примените его к своей ветви разработки.

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

В последнее время я отстаиваю философию «ветви и слияния» в качестве последнего результата. Я думаю, что это печальная истина в том, что работа со слияниями кода из ветвей не является технической проблемой, но это задача, которая познавательно сложна: я думаю, что просто человеческий мозг не отслеживает достаточно деталей, чтобы упростить его. Более того, мне еще предстоит увидеть, как разветвление и слияние действительно работают на практике. Как только код разветвляется, опыт подсказывает мне, что объединить его - не проблема.

Дисциплинированный подход «релиз на основе» работает хорошо.

Ветвление SVN не должно быть гибким. Я хотел бы предложить вашу первую проблему в SVN; Переход от этого откроет новые возможности.