Я перерабатываю наш рабочий процесс для выпуска.Итак, я нашел этот вопрос.Я решил написать свой опыт.Для чего это стоит ...
Для разработки мы используем то, что кажется изменением того, что вы называете stable / default workflow (конечно, все проходит через командыкоторые обеспечивают рабочий процесс, я называю их myw после этого):
- у нас есть центральный сервер, который содержит все наши репозитории
- у нас есть центральный stable клон на проект на этом сервере
- у нас есть центральный клон dev на проект, который изначально является клоном stable на этом сервере
- ,
myw create theproject можно создать клоны stable / dev для проекта на сервере и локально (на компьютере разработчика) - , когда кто-то должен разработать новую функцию, которую он может
myw clone theproject dev mygreatfeature that: - клонирует проект dev репо на сервере как mygreatfeature
- локально клонирует клонированное репо mygreatfeature
- делает много полезных вещей, таких как updating hgserver / hudson ci ...
- он может
myw fetch dev и myw fetch stable в любое время - когда функция завершена, он объединяет ее со своим локальным клоном разработчиканажмите объединенный результат на центральном клоне dev и закройте центральный клон, который некоторое время архивируется:
myw close theproject mygreatfeature
Все это прекрасно работает и довольно плавно.Мы предпочли клоны именованным ветвям, поскольку было действительно просто закрыть функциональную ветвь, и в то время как ртутная часть «именованной ветви» казалась «незавершенной работой».
Релизная частьрабочий процесс в настоящее время выполняется в основном так:
- "мастер релиза" выбирает из центрального клона dev его локальный клон dev .
- он выбирает из центрального стабильного клона свой локальный стабильный клон.
- он выбирает из своего локального стабильного клона изменения, которыенаходятся в своем локальном клоне dev .
- он проверяет все, если все в порядке, сделайте
myw release 1.2.3_RC2 что: - тег с 1.2.3_RC2
- подтолкнуть к централизованному проекту стабильный клон.
- на самом деле это кандидат на выпуск , который некоторое время будет тестироваться нашим CI-сервером и нашими хардкор-тестерами.
- Ошибкаисправления, обнаруженные этими тестами, исправляются в локальном клоне stable и помещаются в централизованный клон stable .
- , когда все в порядке, "мастер-релиз" выполняет формальноеrelease:
myw release 1.2.3
Это работает довольно хорошо, даже если нам нужно улучшить некоторые команды, чтобы сгладить процесс.Один из главных недостатков - большое количество клонов:)
Для управления старыми выпусками у нас в настоящее время имеется клон stable для каждого основного выпуска.Поскольку нет большой необходимости в бэкпорте многих функций, нам просто нужно выбрать некоторые действительно плохие ошибки с hg transplant (кстати, отличное расширение).
Мы использовали это примерно длягод, и нам, конечно же, нужно улучшить наши самодельные команды, особенно для релизной части :)
Основной недостаток заключается в том, что вы должны предоставить вам / вашей команде некоторые инструменты, чтобы справиться с этим, потому что без них это может быть неуправляемымотсюда наш myw самодельный набор команд.Как обычно, ветвь функций не должна длиться слишком долго, иначе слияние может быть затруднено.Такие вещи, как рефакторинг / переименование, должны выполняться в выбранных точках, или это даст вашей команде много работы по слиянию.
Поскольку у нас будет все больше и больше версий для поддержки, я пытаюсь улучшить часть управления «старый релиз, но должен поддерживать».Читая Берт F комментарий, я прочитал эту замечательную статью .Есть хорошие идеи, и это хорошо объясняется по-настоящему хорошей схемой!Кажется, кто-то реализовал версию hg своего инструмента git-flow как hg-flow .Что-то, чтобы рассмотреть.Мне нравятся ветки релизов и исправлений.И я думаю, что принудительное выполнение такого рабочего процесса с помощью инструмента довольно хорошо обязательно!
my2c