Maven Mercurial Выпуск Процесс - PullRequest
       47

Maven Mercurial Выпуск Процесс

4 голосов
/ 02 февраля 2012

Мы недавно перешли на Mercurial. После просмотра этого полезного видео: http://www.youtube.com/watch?v=-k2vLKOUb8s&noredirect=1

Я пытаюсь реализовать процесс выпуска, который позволяет следующее: - релиз maven не зависит от текущей работы разработчиков - исправьте выпущенные версии и затем верните исправления в dev

До сих пор я придумал это: Repo Arch

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

У меня проблема с плагином Maven Release. Если я выпускаю 1.0.0-SNAPSHOT, я получаю следующее в стабильном репо: 1.0.0-SNAPSHOT-> 1.0.0-> 1.1.0-SNAPSHOT

Теперь я могу отправить это обратно в репозиторий dev, и разработка продолжится на 1.1.0-SNAPSHOT. Пока все хорошо.

Но как лучше всего управлять выпуском 1.0.0 и последующими исправлениями? Должен ли я создать ветку из точки фиксации 1.0.0 или другого клона? Есть ли какой-то другой способ управлять им, чтобы разработчик, выполняя исправление 1.0.1, мог легко применить его, а также перенести исправление обратно в dev?

Ответы [ 2 ]

3 голосов
/ 02 февраля 2012

Ваша настройка звучит довольно хорошо. Я бы сделал новую долгосрочную именованную ветвь на основе набора изменений с выпуском 1.0.0. Сохраните вашу разработку в default ветви и создавайте ветви для каждого выпуска.

Здесь я пишу номер версии в POM выше и ниже наборов изменений, а название ветви до конца слева:

          1.0.0-SNAPSHOT    1.0.0    1.1.0-SNAPSHOT
default:  o --- o --- o --- o ------ o --- o --- o --- o --- o --- o
                             \                              /
1.0.x:                        o --- o --- o --- o -------- o --- o --- o
                              1.0.1-SNAPSHOT    1.0.1      1.0.2-SNAPSHOT

Итак, вы счастливо работаете над версией 1.0.0-SNAPSHOT, используя ветку default. Когда пришло время для выпуска, плагин делает набор изменений с 1.0.0 и немедленно другой набор изменений с 1.1.0-SNAPSHOT, все в ветви default.

Вы можете перейти на версии 1.0.x сейчас или позже - не имеет значения. Когда ты делаешь свою ветку

$ hg update 1.0.0  # <- this is a tag
$ hg branch 1.0.x
# edit the POM to change version to 1.0.1-SNAPSHOT
$ hg commit -m "Started 1.0.x branch"

Разработчики теперь всегда могут использовать

$ hg update 1.0.x  # <- this is a branch

чтобы получить последние изменения в этой ветке, и hg update default чтобы вернуться к основной линии разработки. Когда изменения будут зафиксированы в ветке 1.0.x, вы захотите объединить их обратно в default, чтобы ошибка там также была исправлена:

$ hg update default
$ hg merge 1.0.x
$ hg commit -m "Merge in bugfix-123 from 1.0.x"

Выбор между одним или двумя репозиториями на вашем сервере обычно не имеет значения сейчас. Вы используете именованные ветви, чтобы различать стабильные наборы изменений (они на 1.0.x) и менее стабильные наборы изменений (они на default). Однако часто имеет смысл хранить репозиторий на сервере для каждого стабильного выпуска. Вы можете настроить работу в Jenkins или использовать cronjobs для выполнения

$ cd foo-1.0.x
$ hg pull --branch 1.0.x

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

[hooks]
changegroup.1.0.x = hg push --branch 1.0.x ../foo-1.0.x
changegroup.1.1.x = hg push --branch 1.1.x ../foo-1.1.x

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

0 голосов
/ 02 февраля 2012

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

...