Как доставить несколько версий приложений без путаницы?

Question

В настоящее время мы работаем над несколькими ветками нашего веб-приложения.VCS на выбор - SVN.

У нас есть:

• v1: / trunk, живое приложение, исправление ошибок

• v2: / branch / 1, дополнительные функции, без исправлений ствола

Запланировано больше шагов.Текущий план состоит в том, чтобы иметь стабильный и принятый клиентом v1, а затем объединить v2 с v1.В этот момент наверняка появится v3.

Проблема в том, что клиенту нужна большая прозрачность, он в настоящее время может только видеть и тестировать v1.Если бы я сделал v2 доступным для них, очень вероятно, что они не смогут отличить версии друг от друга и сообщать о v1 (исправленных) ошибках снова для v2.Это было бы беспорядок, IMO.Мне также не нравится идея ежедневного слияния, потому что было бы еще сложнее отличить новые и старые ошибки.

У меня такое ощущение, что это скорее проблема нашего процесса разработки, чем технического.,Приветствуются любые идеи для решения проблемы или для того, чтобы обе стороны чувствовали себя более комфортно в отношении будущего развития.Спасибо.

edit

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

edit2

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

Answer 1

Я согласен с вами, другие коллеги постеры.c0rnh0li0 Вам необходимо переосмыслить свои правила регистрации и слияния.

Посмотрите на макет своего репозитория и попытайтесь определить правила, которые могут легко повторяться любым пользователем в команде и которые помогают вносить изменения, соответственно, из стабильного в нестабильный.Для меня это позволяет выполнять слияние в основном в одном направлении.

Пример макета для сценария ветки обслуживания

branches/v1
-approved and shipped/deploy
-Only bugfixes allowed

branches/v2
-is not approved by the client but nearly ready
-Fixes and feature-commits allowed that focus on getting v2 stable & ready
-receive bugfixes commited in v1 (merge down)

branches/v3
-is not approved by the client and far from ready
-Fixes and feature-commits allowed that focus on getting v3 stable & ready
-receive bugfixes commited in v2 (merge down)

trunk
-All syntax-error free commits allowed (mainline)
-receive merges from LATEST stable branch (merge down from v3 in this case)

Верхняя ветвь самая старая с наименьшим количеством функций, новысокая стабильность (хорошо проверено, в недавнем прошлом не было добавлено много новых функций).С другой стороны, ствол довольно нестабилен и имеет передовые черты.v2 и v3 - это что-то среднее.Вы также можете добавить подвиги «под» стволом, которые будут даже более нестабильными, чем ствол.Направления слияния остаются прежними.Я хотел бы процитировать мантру «объединить, скопировать».

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

Я не упомянул теги здесь.Если вы можете создавать их и не выпускать из ветки напрямую.

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

---

Визуализация происхождения приложения VCS для клиента

Возможности:

• Если это хост веб-проекта, версии на URL-адресах, которые содержат название ветви
• Для любого проекта: просто отметьте логотип или текстовое свойство, которое содержит что-то вроде «версия 3.x», иотобразите его в своем приложении
• Самое классное решение - использовать svn ключевые слова и проанализировать значение $ HeadURL $ в вашем приложении, чтобы динамически отобразить имя ветви, из которой эта сборка происходит от

Answer 2

1. "без исправлений ствола"
2. "было бы еще сложнее отличить новые и старые ошибки."
3. "У меня такое ощущение, что это больше проблема снаш процесс разработки, чем технический. "

Чертовски прямо.Ваш процесс разработки не может распознать сбои в V1.Как можно надеяться, что V2 будет лучше, чем V1, если вы не перенесете исправления в V1 в V2?!

Исправления ошибок всегда важнее новых функций.Если старые функции сломаны и их не стоит исправлять, удалите их .

Отстаньте от ленивой задницы;Если вы или кто-то другой приложил усилия для исправления дефекта в V1, убедитесь, что он не появляется в V2.ПОЧИНИ ЭТО!Если ваш код настолько мусор, что это происходит ежедневно, прекратите работать на V2 и сосредоточьтесь на том, чтобы исправлять ошибки реже.Если вы не можете заставить функции V1 работать должным образом, вы никогда не доберетесь до V3.

Я мог бы также предложить "mercurial" или "git" или "bazaar", а не svn.Они намного лучше справляются с типами управления, если вы находите и используете функции «выборки вишен» и «очередь»: вы можете добавить функцию и использовать «ОДИН, что руководство думает, будет сохранять» в производстве.не вытащив всех остальных недоделанных идей, которые они придумали, а затем забросили.Если политика не позволяет перейти к распределенному контролю версий, просто используйте его сами и отправляйте только то, что вы поставляете (и они хотят), в svn.

Answer 3

Мне кажется, что вы поменяли термины ветка и ствол. Обычно транк - это активная ветка разработки, где релизы живут в своих ветках с исправлениями ошибок. Похоже, что вы используете trunk как ветку исправления release1, в то время как / branch / 1 является реальной веткой разработки, и застряли, так как вы не можете создать вторую транк для release2.

Если я прав, я бы порекомендовал переместить ваш текущий ствол в ветвь / branch / v2, а вашу ветвь / branch / 1 - в / trunk. В этом сценарии вы можете иметь столько веток релиза, сколько вам нужно (но старайтесь держать их как можно ниже), пока основная линия разработки находится в /trunk.

Подробнее см. http://nvie.com/posts/a-successful-git-branching-model/. Хотя это для git, есть много VCS-независимой информации.

Answer 4

Кажется, что-то неорганизованное. Слияние версии 2 с версией 1? А? С какой версией вы остались? Все еще версия 1? С функциями версии 2? Wha ..

Что мне нравится для небольших проектов:

Магистраль: это то, где вещи совершаются, когда разработчик уверен, что это работает. Провести внутреннее тестирование качества на магистрали.

Теги: создайте новый тег для каждого выпуска, скопировав из ствола. Назовите ваши теги "/tags/v1.0" или "/tags/v1.1" или как хотите. Если вам нужен внешний клиент для проверки чего-либо, назовите ваш тег как-то вроде "/tags/v1.0-beta" и дайте им это для проверки. Не позволяйте им тестировать со стволом, потому что пока они тестируют, вы все равно будете разрабатывать!

Ветви: Если у вас есть функция, для разработки которой требуется некоторое время, вы не можете зафиксировать ее в стволе до того, как она будет готова. Сделай ветку. Назовите его в честь реализуемой вами функции, например "/branches/user_logins".

Исправления исправляются в стволе и включаются в следующий помеченный выпуск. Если есть экстренное исправление, которое должно быть выпущено СЕГОДНЯ, но в стволе есть что-то, что еще не может быть выпущено, сделайте еще один тег, но скопируйте его из тега выпуска с ошибками, а не из ствола, назовите его как-то типа «v1. 0.1 ", исправьте ошибку там, дайте им новую версию, а затем объедините это исправление в ствол.