Я бы сделал ваш каталог DocumentRoot подкаталогом первого уровня вашего репозитория, и вот несколько причин, почему:
- Если вы используете что-то вроде Apache для управления вашим сервером, вы можете поместить другиеметаинформация, например файлы конфигурации с доступными сайтами и с включенными сайтами, в одном каталоге, поскольку они на самом деле не являются частью документов сайта.
- Точно так же вы можете сохранить каталог "docs" правильнорядом с кодом.
- Если корнем вашего хранилища является ваш DocumentRoot, при прочих равных условиях вы также обслуживаете свой каталог .hg, где находится вся история вашего хранилища, и ваш файл .hgignore, такого родавещи.Конечно, это можно исправить с помощью файла .htaccess, но проще просто иметь дочернюю папку.
По сути, кодовые базы, как правило, не совсем соответствуют друг другу с развернутыми сайтами,поэтому я склоняюсь к тому, чтобы корневой каталог документа был подкаталогом.Это действительно зависит от ваших потребностей относительно того, что вы делаете, но вот что я делаю:
Я запускаю на своем компьютере экземпляр VirtualBox , который выглядит как можно ближе на то, как выглядит мой развернутый сервер, по крайней мере, настолько близко, насколько я могу получить файлы конфигурации.Я бы сказал, что этот подход менее подвержен ошибкам, чем дополнительная запись VirtualHost.В зависимости от проекта, я могу сделать это идентичным минус, возможно, некоторые записи DNS, поэтому я могу установить все, чтобы указать либо на test.myproject, либо на production.myproject, и этот I всегда автоматизировать (Iиспользуйте chef , но это является излишним для меньшего проекта), чтобы его можно было тестировать, и чтобы он не шутил.Нет ничего хуже, чем запускать дымовые тесты, которые стирают вашу базу данных - и конфигурация случайно указывает на вашу базу данных.Запуск виртуальной машины позволяет безболезненно тестировать обновления в среде или ОС вашего сервера, а также можно обнулить и восстановить снимок, если вы хотите перейти к более раннему состоянию конфигурации машины.
Если вы действительнохотите запретить доступ разработчиков SSH к вашим компьютерам - и IMO, это плохая идея, потому что, если у вас есть проблемы на рабочем сервере, вы помешали своим разработчикам диагностировать или исправить - тогда я думаюЛучше всего использовать что-то вроде hudson , который представляет собой среду непрерывной интеграции.Вы предоставляете ssh доступ только пользователю Hudson для запуска сценария развертывания, но любой (с правами доступа, установленными в Hudson) может выполнить это задание.Фактически, это удобно иметь в среде, где у вас есть, например, некоторые сотрудники по управлению продуктами, которые вы хотите иметь возможность обновлять производственный сервер, не имея возможности войти в систему. В этой версии «для бедных» используется sudo, чтобы позволитьВаши разработчики запускают команду от имени другого пользователя, который имеет , имеет доступ по SSH - и разрешает им только запускать скрипт публикации.
Я все равно рекомендовал бы дать вашим разработчикамдоступ к вашей машине, хотя вам не нужно передавать ключи от королевства.Просто создайте группу «разработчиков», назначьте ей своих разработчиков и предоставьте ей достаточно разрешений, чтобы играть с необходимыми каталогами сервера, и у вас все получится.