Новое в Mercurial и VCS: настройка нескольких серверов с общим кодом

Question

В нашем небольшом офисе мы настраиваем Mercurial - мы впервые используем «настоящую» систему контроля версий.У нас есть три сервера - живой сервер, промежуточный сервер и сервер разработки.

У нас также есть три относительно больших веб-сайта - один для посетителей, один для пользователей и сайт для интрасети, дляофисный персонал.

Три веб-сайта имеют общий код.(например, библиотека классов php, некоторые часто используемые фрагменты кода и т. д.)

До контроля версий мы просто использовали символические ссылки для связи с общими библиотеками.Например: каждый сайт имел символическую ссылку на каталог «ObjectClasses» - любые изменения, внесенные в файл в ObjectClasses, будут мгновенно доступны для всех сайтов.Вы просто загрузите измененный файл в стадию и вживую, и все готово.

Но ... Mercurial не следует по символическим ссылкам.Итак, я настроил под-репозиторий для разделяемых библиотек на трех сайтах на трех серверах (фактически «четыре» сервера, если учесть тот факт, что на сервере разработки есть два программиста с двумя отдельными клонами хранилища).

Итак, существует 12 рабочих копий библиотеки общих объектов.

Итак, вот вопрос:

Есть ли способ упростить описанную выше настройку?

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

Программист A вносит изменения в Object Fooв подпункте на Сайте 1. Он хочет сделать это доступным везде, поэтому он фиксирует это, а затем отправляет его на промежуточный сервер.Я установил хуки на промежуточном сервере, чтобы автоматически распространять изменения на три сайта, на промежуточный сервер и снова на три сайта на живом сервере.Это заботится о 6 рабочих копиях на промежуточном и живом серверах.Пока все хорошо.

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

Программист А теперь должен вручную перетащить общий подпункт на сайты 2 и 3 на сервере разработки.Он также должен сказать Программисту B, чтобы он вручную извлекал общую подпункт на Сайтах 1, 2 и 3 в своей копии сайта на сервере разработки.Что если он редактирует Object Foo на Сайте 1 и вносит различные изменения в Object Foo на Сайте 2. Ему придется разрешить два отдельных конфликта.

Мы вносим изменения в объекты относительно часто.Это сведет нас с ума.Мне очень нравится идея контроля версий - но после двух недель борьбы с попытками найти лучшую настройку, старый небрежный способ иметь одну копию общих файлов и выкрикивать: «эй - я работаю над этим файлом, я хочу сделатьизменение "выглядит довольно хорошо прямо сейчас.

Неужели нет более простого способа настроить это?

Answer 1

Без дополнительной информации о конкретной веб-платформе и технологиях, которые вы используете (например, .NET, LAMP, ColdFusion и т. Д.), Этот ответ может быть неадекватным, но все же позвольте мне сделать попытку.Во-первых, если я вас правильно понимаю, проблема в вашей рабочей парадигме.Вы предлагаете разработчикам вносить изменения в файлы, а затем отправлять их на три разных сайта.Я предлагаю полностью отделить задачи разработки от проблем сборки / развертывания.

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

Если вы хотите автоматизировать этот процесс, есть ряд инструментов, которые могут это сделать.Я обычно предпочитаю NAnt с CruiseControl для интеграции сборки, но тогда моя работа - это, в основном, .NET, что делает его идеальным вариантом.Если вы можете предоставить больше подробностей, я могу предоставить больше деталей, если хотите, но я думаю, что основная проблема, которую вы должны преодолеть, - это способ обработки рабочего процесса.Используйте Mercurial, чтобы несколько разработчиков были довольны извлечением / извлечением из одного репозитория, а затем заботитесь о развертывании на своих серверах для тестирования в качестве отдельного шага.