Переход от Subversion к Mercurial - как адаптировать рабочий процесс и системы постановки / интеграции?

Question

Мы все взволнованы от svn до hg, и поскольку рабочий процесс разработки более или менее продуман, здесь остается самая сложная часть - система подготовки и интеграции.

Надеюсь, этот вопрос пойдет немного дальше, чем ваше общее «как мне перейти с xxx на Mercurial». Пожалуйста, простите за длинный и, вероятно, плохо написанный вопрос:)

Мы - веб-магазин, который выполняет множество проектов (в основном PHP и Zend), поэтому у нас есть одно огромное хранилище SVN, с более чем 100 папками, каждая из которых представляет проект со своими собственными тегами, ветвями и стволом, конечно. На нашем сервере интеграции и тестирования (где QA и клиенты смотрят на результаты работы и тестирование) все в значительной степени автоматизировано - Apache настроен на подбор новых проектов, автоматически создавая vhost для каждого проекта / транка; Сценарии миграции mysql прямо в транке тоже, и разработчики могут применять их через простой веб-интерфейс. Короче говоря, наш рабочий процесс таков:

1. Код проверки, работай, коммит
2. Запустить обновление на сервере через веб-интерфейс (это в основном делает svn на сервере в конкретном проекте, а также при необходимости запустить скрипт db -igration)
3. Изменения качества на сервере

Этот подход, безусловно, неоптимален для больших проектов, когда над одним и тем же кодом работают более 2 разработчиков. Ветвление в SVN только вызывало больше головных болей, следовательно, переход на Mercurial. И вот в чем вопрос: как организовать эффективный сервер подготовки / интеграции / тестирования для такого типа работы (когда у вас много проектов, скажем, один разработчик мог бы работать над 3 различными проектами за один день).

Мы решили использовать отслеживание веток по умолчанию, а затем внести все изменения в отдельные ветки. В этом случае, однако, как мы можем автоматизировать промежуточные обновления для каждой ветви? Если раньше для одного проекта мы почти всегда работали с транком, то нам нужна была одна БД, один vhost и т. Д. Теперь мы потенциально говорим о N-базах данных для каждого проекта, конфигах N-vhost и т. Д. Тогда что насчет CI (таких как запуск phpDocumentor и / или модульных тестов)? Это должно быть сделано только по умолчанию? По веткам?

Интересно, как другие команды решают эту проблему, возможно, некоторые лучшие практики, которые мы не используем или не замечаем?

Дополнительные примечания:

Вероятно, стоит упомянуть, что мы выбрали Kiln в качестве хостинга репо (в основном, так как мы все равно используем FogBugz)

Answer 1

Это ни в коем случае не полный ответ, который вы в конечном итоге выберете, но вот некоторые инструменты, которые, вероятно, будут влиять на него:

• репозитории без рабочих каталогов - если вы clone -U или hg update null, вы получите репозиторий без рабочего каталога (только .hg). Они лучше на сервере, потому что занимают меньше места, и никто не испытывает соблазнов редактировать там
• changegroup крючки

Для этого последнего хук changegroup запускается всякий раз, когда один или несколько наборов изменений приходят через push или pull, и вы можете сделать так, чтобы он делал некоторые интересные вещи, такие как:

• подтолкнуть наборы изменений к другому репо в зависимости от того, что поступило
• обновить рабочий каталог принимающего репо

Например, можно автоматизировать что-то подобное, используя только инструменты, описанные выше:

1. разработчик отправляет пять наборов изменений в central-repo / project1 / main
2. последний набор изменений находится в ветке 'my-эксперимент', поэтому csets автоматически перетаскиваются в опционально созданный репо central-repo / project1 / my-эксперимент
3. central-repo / project1 / my-эксперимент автоматически выполняет hg update tip, который обязательно находится в my-expiriment ветви
4. central-repo / project1 / my-эксперимент автоматически запускает тесты в своем рабочем каталоге и, если они проходят, выполняет развертывание 'make dist', которое может также настроить базу данных и vhost

Важное замечание, и глава 10 в книге по ртути охватывает это, состоит в том, чтобы не заставлять пользователя ждать этого процесса. Вы хотите, чтобы пользователь подтолкнул к репо, который содержит, возможно, нормальный код, а автоматизированный обработчик выполняет CI и развертывает работу, которая, если он пройдет, в конечном итоге станет репо с вероятным одобрением.

В самой большой ртутной установке, в которой я работал (около 20 разработчиков), мы дошли до того, что наша система CI (Hudson) периодически извлекала из репозиториев «возможно, все в порядке» для каждого, затем создавая и тестируя, и обрабатывая каждая ветка отдельно.

Итог: все инструменты, которые вам нужны для настройки того, что вам нужно, вероятно, уже существуют, но склеивание их будет единовременной работой.

Answer 2

Следует помнить, что DVCS (по сравнению с CVCS) вводит другое измерение для управления версиями:
Вам больше не нужно полагаться только на ветвление (иполучить промежуточную рабочую область из правой ветви)
Теперь у вас есть с DVCS рабочий процесс публикации (push / pull между репо)

Значение вашей промежуточной средытеперь репо (с полной историей проекта), извлеченное в определенной ветке:
Многие разработчики могут выдвинуть много разных веток в это промежуточное репо: процесс выверки может быть выполнен изолированно в этом репо, в "главная "ветка по вашему выбору.
Или они могут вытащить эту промежуточную ветку в своем репо и протестировать вещи перед тем, как их оттолкнуть.

альтернативный текст http://hginit.com/i/02-repo.png
^{Из учебника Джоэла по Mercurial HgInit}

Разработчику не нужно обязывать других видеть: процесс публикации в DVCS позволяетего / ее в пуСначала перейдем к промежуточному этапу, локально урегулируем любой конфликт и , затем перейдем к промежуточному репо.