Я хочу реализовать следующий рабочий процесс для сценария непрерывной интеграции с использованием Mercurial / Jenkins - PullRequest
2 голосов
/ 22 марта 2011

Основной репозиторий, где регистрируются все разработчики, скажем, находится по адресу http://hg.main.com:8000/project

Теперь у нас также есть http://hg.qa.com:8000/project, где весь последний код должен находиться в синхронизации, плюс тесты и другие артефакты находятся в этом хранилище. который будет ТОЛЬКО «вытолкнут» в центральное хранилище, если 85% тестов пройдут.

  1. Есть ли лучший способ реализовать это?
  2. Какие команды hg мне понадобятся, чтобы убедиться, что я не перезаписываю последние коммиты

1 Ответ

0 голосов
/ 22 марта 2011

начни с чего-то вроде: Управление утверждением: Аудит и QA

Для кого?

Если вам нужна явно одобренная история кода с полным послужным списком с помощью команды разработчиков и отдельной команды QA, этот рабочий процесс может быть правильным для вас.

Требования

Вам нужен только Mercurial (командная строка), общий репозиторий для обмена данными (достаточно простого SSH-сервера, как и один частный репозиторий bitbucket) и GpgExtension.

Поток

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

Преимущество состоит в том, что слияние по умолчанию с QA требует явного слияния, которое впоследствии может быть подписано GPG разработчиком, ответственным за него.

Когда QA заканчивает применять свои изменения, они сначала сливаются обратно в настройки по умолчанию (чтобы разработчики работали над версией QA), а затем сливаются в выпуск, GPG подписывает коммит слияния.

Разработчик

hg pull # get the latest changes
hg update
hg commit -m ""
hg update -C QA
hg merge default
hg commit -m "merged default branch for QA"
hg sign
hg push

QA

hg pull
hg update QA
hg commit -m "QA fixes"
hg update -C default
hg merge QA
hg ci -m "merged QA fixes back into the development branch"
hg update -C release
hg merge QA
hg commit -m "merged finished QA into release"
hg sign

Модификация

Если вам нужно больше слоев, чем просто разработчикам и QA, просто добавьте дополнительные именованные ветви, например, staging-release перед выпуском.

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

...