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

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

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

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

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

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

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

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

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

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


continuous-integration installation staging mercurial
person Alex N.    schedule 15.07.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

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

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

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

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

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

person Ry4an Brase    schedule 15.07.2010
comment
Гораздо более подробный ответ, чем мой. +1. Мне нравится, что активный push автоматически обрабатывается на удаленном сервере. - person VonC; 16.07.2010
comment
Спасибо, VonC и Ry4an - оба ваших ответа действительно очень полезны. Заставил меня думать в правильном направлении (надеюсь :) - person Alex N.; 16.07.2010

arrow_upward
2
arrow_downward

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

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

alt text
Из учебника Джоэла по Mercurial HgInit

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

person VonC    schedule 15.07.2010
comment
Спасибо, VonC и Ry4an - оба ваших ответа действительно очень полезны. Заставил меня думать в правильном направлении (надеюсь :) - person Alex N.; 16.07.2010