Использование репозитория hg в качестве веб-сайта

Question

Это в некоторой степени связано с моим секретным вопросом здесь . Это плохая идея использовать репозиторий hg / mercurial для живого сайта? Если так, то почему?

Кроме того, у нас есть веб-сайт для разработки, тестирования и производства, например dev.example.com, test.example.com и www.example.com. Если использование репозитория для живого / производственного веб-сайта плохая идея, можно ли использовать репозиторий hg для сайтов разработки и тестирования?

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

Какой лучший способ добиться этого?

Edit: Наш «сайт» на самом деле является многосайтовой CMS-установкой с главным репозиторием и несколькими подкаталогами. Макет структуры хранилища:

/root [main repository containing core files and subrepositories]
    /modules [modules subrepository]
    /sites/global [subrepository for global .css and .php files]
    /sites/site1 [site1 subrepository]
    ...
    /sites/siteN [siteN subrepository]

Инженеры-программисты будут работать в репозиториях root, modules и sites/global. Менее технические люди (веб-дизайнеры) будут работать только в подкаталогах site1 ... siteN.

Answer 1

Многие люди хранят свои сайты в репозиториях, и пока у вас нет людей, которые редактируют живой сайт у вас все в порядке. Создайте область подготовки / разработки, где ваши пользователи, не имеющие правок, вносят свои изменения, а затем попросите кого-нибудь более дружественного к RCS периодически выполнять цикл commit-pull-merge-push.

До тех пор, пока осознанное действие судящего человека выполняет постановочную область -> подталкивание к репо - все в порядке. Вы даже можете поместить хук в рабочий клон, который автоматически выполняет «hg update» рабочего каталога в этом рабочем клоне, так что «push» - это все, что требуется для развертывания.

Тем не менее, я думаю, что вы недооцениваете свою веб-команду или черепаху; они могут получить это.

Answer 2

Да, это плохая идея.

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

Однако на самом деле я рассматриваю эту «концепцию» (управление исходным кодом как развертывание) с помощью инструмента, который я написал (несколько других компаний также занимаются этой темой сейчас, так что вы увидите это подробнее). Мой для SVN (на данный момент), так что это не особенно актуально; Я упоминаю об этом только для того, чтобы показать, что я рассматривал это ранее (но не в Repository, хотя; рабочая копия, в этом сценарии ответ тот же: лучше иметь не-версию "free" как каталог веб-сайта, автоматизировать (посредством действий пользователя) копирование «версионных» данных в этот каталог).

Answer 3

лично я (я команда из 1), и мне очень нравится идея использовать src control в качестве живого сайта. больше с hg, то с svn.

как я вижу, вы можете загрузить весь сайт (добавить / удалить файлы) с помощью одного cmd намного проще, чем это через ftp / ssh, удалить это и т. д.

если вы используете apache (и, вероятно, iis), вы можете создать простой файл .htaccess, который будет блокировать все файлы .hg (или .svn, если вы используете svn)

моя предпочтительная структура Сайт разработки находится на локальной машине, работающей непосредственно из репозитория (здесь на самом деле не требуется безопасность, делайте что хотите, фиксируйте как требуется)

промежуточная / тестовая машина - это отдельная коробка или виртуальная машина, на которой запущена свежая копия действующей базы данных (У меня есть сценарий для отправки подтвержденных изменений на промежуточный сервер и запуска тестов)

живая машина (откройте ssh-соединение, отправьте изменения на работающий сервер, протестируйте снова, все это можно написать достаточно легко, примеры для google)

из-за природы hg push / pull, это означает, что вы можете фиксировать изменения и тестировать без опасности перенести сломанную сборку на живой сайт. Как вы говорите в своих комментариях, только определенные люди должны иметь разрешение на размещение версии на живом сайте. (если это не удастся, вы легко сможете вернуться к предыдущей версии через управление src)

Answer 4

Почему бы и репо не быть активным веб-сервером (в любом случае для dev или test / QA)?

Вот что я пытаюсь реализовать:

• Разработчики имеют локальные тестовые среды, в которых они могут создавать и тестировать свой код
• Разработчики создают клон среды разработки на своей локальной машине разработки
• Разработчики обязуются делать так часто, как хотят, в локальное репо
• Когда часть работы выполнена и протестирована, тогда разработчик отправляет рабочие наборы изменений в dev repo

Изменения будут объединены и протестированы на Dev, затем отправлены в Test / QA и так далее.

Кстати, мы используем Mercurial. Я считаю, что эта модель будет работать только с использованием инструмента управления распределенным исходным кодом.