Какова хорошая практика SVN для выпусков функций / ошибок?

Question

Я читал несколько вопросов здесь, на StackOverflow, но не очень доволен. Ситуация, в которой я нахожусь, следующая:

Большой проект веб-приложения (сложные части, несколько неизвестных):

транк основной стабильный релиз

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

теги Я в основном использую теги для разных выпусков, у нас есть три среды: production, sandbox и dev ... выпуск тегов помогает поддерживать постоянный номер редакции в env, так что в любой момент время, когда мы можем сравнить, какой номер выпуска использует среда

Так что правильно, я не делаю большую часть своей работы в ветвях, сливаюсь обратно в транк и создаю выпуск тегов. среда разработки обычно имеет сборку, в которой есть все последние исправления / дополнения ошибок. Как правило, есть обзор dev env, и некоторые функции / ошибки считаются стабильными, после чего я объединяю эти специфические функции в транк. Другие рассматриваются и, возможно, потребуется дополнительная работа, в этом случае я иду в конкретную ветку и вносить изменения.

Боль, которую я чувствую, заключается в том, что у меня есть dev и trunk, и я должен объединить ветки функций / ошибок в каждой. Просто кажется таким сложным и громоздким. Я правильно делаю, есть ли лучший способ / практика, более легкая практика? Или я делаю это совершенно неправильно, и в этом случае мне нужен лучший способ!

Answer 1

Я предпочитаю этот сценарий:

• Разработка в стволе для тривиальных изменений или в ветви функций / исправлений для более крупных работ.
• Также есть ветви для сред ивыпущенные версии.например, «production», «stage»
• Теги должны быть окончательными, т.е. не фиксировать теги.

Итак, пример жизненного цикла:

Разработка

• У некоторых разработчиков в стволе и в ветках ошибка-1, ошибка-2, функция-1 и особенность-2.После того, как вы проверили ошибки и функции, объедините стабильные в магистраль (например, объедините ошибку-1, ошибку-2 и функцию-1).

Функция завершена:

• Как только вы будете готовы ввести код в очередь, вы можете разветвлять транк в «стадию» ветвления, любой код, который раньше был в стадии, будет заменен кодом транка.Сценическая система всегда выполняет сборку сценического кода, чтобы вы могли тестировать.Разработка может продолжаться в стволе и ветви функций / ошибок.

Релиз:

• Как только ветвь стадии становится достаточно стабильной, вы можете ветвить ее в ветке релиза.Разветвите его в ветке с названием «release-1.X» и пометите эту версию как «release-1.0.0».Рабочий сервер может выполнить сборку тега release-1.0.0.Ничего не добавляйте к этому тегу.

Исправление:

• Если вы заметили ошибку в рабочем коде, вы можете исправить ее в стволе, объедините исправление черезэтапы вплоть до ветки релиза 1.X, а затем пометьте фиксированную версию как 1.0.1 и дайте указание производственным серверам запустить сборку этой новой версии.

Answer 2

Честно говоря, ваша практика мне подходит, сказав, что если ошибка не займет много времени / кода, я бы посоветовал просто проверить разработчика и сделать там исправление, а затем просто проверить правильность исправления.в хранилище Dev.

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