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

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

Это НЕ общая "лучшая практика управления релизами" или вопрос CI, как это было спросил many раз с хорошими ответами, и там доступно огромное количество литературы, чтобы убить время.

Я только прошу указать конкретные способы использования mercurial в контексте управления выпуском.

Самый очевидный и преобладающий ответ предположительно будет стабильным/по умолчанию, который полностью покрывается красивый блог @Steve Losh, и более кратко в ответе от него. Это просто и эффективно.

Важным примером этой настройки является сам hg. hg использует несколько репозиториев для активной разработки, но для целей управления выпуском все, кажется, содержится в ветвях стабильной/дефиниции main repo.

Настройка hg фактически демонстрирует вариацию, а точнее расширенную версию стабильного /default: клон ветвей. Я описал процесс в ответе на вопрос об именованной ветке и множественных репозиториях (с другим отличным ответом от @Martin Geisler). В моем ответе я забыл упомянуть, как клон работает для рабочего процесса разработчика: если вам нужно исправить ошибку для ветки, вы бы hg clone <main repo>#<branch>, но не клон ветки, потому что ваш набор изменений по-прежнему будет возвращаться к основному репо и автоматически выталкивается в клон. Конечно, вы можете отказаться от клонирования и просто hg update <branch> в вашем основном клоне, но большинство аргументов для использования отдельных клонов (особенно для независимой сборки) применяются здесь.

Теперь вернемся к вопросу: Есть ли другие способы, которые подходят для разных сценариев реального мира?. Например, традиционный цикл релиза основных/второстепенных/патчей с длинным промежутком между релизами, возможно, требует довольно различный рабочий процесс, чем быстро развивающееся веб-приложение "release-как-вы-go". Пожалуйста, также прокомментируйте, к примеру, стабильный/дефолтный и клон-клон, если вы хотите.

Поскольку это почти вопрос опроса, я могу только попытаться принять "лучший" ответ субъективно. Если я смогу получить еще несколько ответов, чем мой вопрос рабочего процесса разработчика, то есть.

Спасибо за все ваши данные!

Ответ 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