Как я должен разветвляться и маркировать до и после релиза?

Question

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

В какой-то момент я хочу сделать ветку как ветку релиза и внести последние изменения в ветку и выпустить ее. Затем после выпуска я хочу сохранить его как тег.

Чтобы уточнить, я ищу соглашения для именования, обработки ветвей и обработки тегов. Мне также интересно, есть ли альтернативы тому, как я говорю об урегулировании ситуации.

• Вы называете ветки выпуска или используете одну и ту же ветку выпуска с новым кодом каждый раз?
• Удалить ветки релиза, если они существуют как теги?
• Как вы называете свои ветки / теги?

Answer 1

Предлагаю прочитать этот ответ

Управление выпуском в SVN

В основном есть одна ветка RELEASE, которую вы можете пометить оттуда, если хотите. И держите самую передовую версию кода в транке

Что касается названия релизов: это зависит от того, что подходит вам лучше всего и кто люди, увидевшие номер релиза.

Подумайте об использовании MajorRelease.MinorRelease, а затем, возможно, где-нибудь для технически заинтересованных пользователей вы даже можете указать номер выпуска патча (автообновления приложения e.gg и major.minor остаются прежними). ​​

Major: большие изменения -> новая функциональность / разрывы совместимости Незначительный: интерфейс совместим (например, производительность) Патч: исправление ошибок

Answer 2

Есть много способов работы. Я использую следующее:

project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
     |
     |- releases //where all release tags are located
     |- daily //where all daily tags are located.

Мы используем следующие названия:

• Для ветвей мы называем ветвь тем, что является основными задачами, которые будут в нем выполняться (например, admin_module_refactor).
• Для тегов мы присваиваем тегам номер версии (mayor.minor.micro. Например: 1.0.2), когда они соответствуют тегу релиза. Или с указанием даты для ежедневных рабочих тегов (например, YY_MM_DD).

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

Answer 3

Вы можете использовать эту информацию в качестве руководства, даже если вы не используете TFS.

Руководство по ветвлению

Answer 4

В какой-то момент я хочу сделать ветку как ветку релиза и сделай любую последние изменения в ветке и отпусти

Это то, что меня беспокоит. Как правило, вы захотите создать ветку, выполнить всю ее разработку, а затем реинтегрировать эту ветку в ствол. Создайте свой тег из этой точки на стволе. Если вы хотите внести дополнительные изменения, создайте новую ветку, отредактируйте, реинтегрируйте и повторно выпустите.

Не пытайтесь вносить изменения в ветку релиза, так как вы можете потерять их или затруднительно слить их обратно в транк.

Альтернативный подход к ветвлению релиза состоит в том, чтобы внести все изменения в развитие ствола и, когда вы будете готовы, создать ветку релиза / тега. Для небольшого магазина разработчиков это обычно самый простой способ. (Другой подход хорошо работает, когда вы вносите большие изменения в продукт, в который вносят изменения и все остальные).

Answer 5

Я автоматизировал процесс сборки с помощью CruiseControl.Net. У нас были сборки, соответствующие номерам сборок, поэтому версия dll была бы 6.5.4.1234. 6 и 5 всегда обновлялись вручную, когда у нас были главные и второстепенные релизы. 4 был обновлен вручную после сборки (и 1234 был также сброшен на 0). Процесс сборки всегда обновлял 1234 до 1235.

Когда мы освобождаемся от транка (версия всегда будет 6.0.0.x), мы вручную разветвляемся и называем его Branch_6_0. Затем ветка будет построена как 6.0.1. Магистраль переместится на 6,1 или 7,0.

В CruiseControl было два режима (dev и test). Тест всегда создавался по требованию и создавал ветку, соответствующую версии сборки.