Я арендовал VPS (Linux - Fedora), и он будет использоваться в качестве веб-сервера для разработки и производства одного и того же веб-приложения.
Я установил yum apache, subversion и все пакеты, необходимые для работы PHP.
В apache я создал два виртуальных хоста:
dev.mydomain.com (for ongoing development, /var/domains/dev.mydomain.com/public_html )
www.mydomain.com (for production, /var/domains/www.mydomain.com/public_html )
Будет только один разработчик, и он будет использовать Netbeans в качестве IDE в Windows XP.
Я могу представить, что первое, что он сделает, - это скопирует копию из репозитория SVN на свой компьютер в Netbeans. Что я собираюсь сделать, так это просто настроить два репозитория SVN в этих папках.
/var/domains/dev.mydomain.com/public_html
/var/domains/www.mydomain.com/public_html
Итак, когда он вносит некоторые изменения в свою локальную копию, а затем фиксирует изменения, он может посетить dev.mydomain.com в своем браузере, чтобы просматривать страницы и выполнять отладку кода.
Позже, когда он думает о кодах в dev.mydomain.com может использоваться в производстве, он может использовать Netbeans для фиксации изменений в www.mydomain.com.
Есть ли проблема с описанным выше сценарием? Вот как должен быть настроен такой веб-сервер?
Предполагая, что вы занимаетесь чистым HTML / графическим дизайном, это должно быть нормально. Если отец является динамичным, особенно если он делает что-то даже отдаленно сложное / интересное / хитрое, я бы не стал настраивать свой производственный блок в качестве блока разработки.
Вам нужна среда разработки, максимально похожая на вашу производственную среду, и использование того же самого окна действительно позволяет добиться этого, но есть несколько проблем. Самым важным является то, что вы можете остановить свой производственный блок, тестируя свою новую разработку. Бесконечные циклы, функции без надлежащего выхода, сбой в базе данных ... Все это (и многое другое) может негативно повлиять на вашу производственную среду.
Мое первое желание, если вы не занимаетесь собственной разработкой, - это арендовать вторую коробку. Моя вторая склонность - купить дешевую коробку для битера, на которой можно воспроизвести окружающую среду. Менее критично, чтобы оборудование было близким к соответствию, чем программное обеспечение. Например, на моей последней работе у нас были высокопроизводительные автономные серверы для малого бизнеса в одном корпусе для управления нашей производственной средой. Нашей тестовой средой была пара eMachines.
Напомним: если вы занимаетесь динамической веб-разработкой, я бы не стал использовать продакшн для ее тестирования. Получите вторую размещенную среду или купите коробку для битера и настройте ее идентично.
Я думаю, что информация о репозитории хранится в рабочей копии, поэтому она не будет фиксироваться в любом указанном месте. Кроме того, информация хранится в формате базы данных, а не в знакомой структуре папок directory / directory / directory / file.html, в которой она хранится для клиента.
Вы хотите rsync. Разработчик выполнит свою обычную проверку svn из репозитория Subversion, как вы обрисовали, но затем, когда он будет готов перейти к производству, вы или он войдете на сервер через ssh и выполните rsync -av --cvs-exclude /var/domains/dev.mydomain.com/public_html /var/domains/www.mydomain.com/public_html. В этом списке все, что было обновлено и одновременно копируется в продакшн, за исключением каталогов .svn.
Удобно иметь возможность фиксировать и публиковать автоматически, по крайней мере, для небольших проектов, но настоящий сценарий развертывания (например, с использованием rsync, как предлагает @Kevin M) обеспечивает лучший контроль и изоляцию производственной среды. Например, некоторые фреймворки зависят от определенных настроек каталога (для кешей, tmp dirs), которые не имеет смысла хранить в Subversion. Сценарий развертывания может убедиться, что эти каталоги существуют и имеют соответствующие разрешения и т. Д.
Если вы хотите, чтобы коммиты автоматически публиковались, вам нужно сделать пару вещей:
Кроме того, если вы зависите от установленного программного обеспечения (php, python и т. Д.). Вы захотите составить план того, как выполнять обновления и тестировать их в среде разработки, прежде чем запускать программное обеспечение в производство. Это сложнее сделать с одним ящиком.