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