внедрение контроля версий для webdevelopment

Question

Я пытаюсь сделать переход в управление версиями, так как мои проекты становятся все больше. В настоящее время мое развитие идет что-то вроде этого:

• Я «живая» версия прошла онлайн
• У меня есть локальная версия, а также локальный веб-сервер
• отредактировать локальную версию и сделать тестирование на мой локальный веб-сервер
• Наконец, я побегу Unison который обновляет живую версию из моей локальной версии (а также обновление моей местной версии с любыми изменениями в живую версию)

моего л ocal - Gentoo, Linux. Я немного посмотрел на SVN, но я думаю, что это может не понравиться моим потребностям, поскольку мой локальный веб-сервер (и Unison) сможет получить доступ только к зарегистрированному в настоящий момент коду и т. Д. Возможно, я ошибаюсь, но об этом я мало что знаю.

Может кто-нибудь, пожалуйста, проведет меня через настройку какого-либо контроля версий на существующий код, который приведет к тому, что последняя версия будет доступна локальному веб-серверу и которая не будет использовать время доступа для неотредактированных файлов? (Я не хочу Unison загрузки каждого файла каждый раз, когда я внести изменения)

Answer 1

Я использую подрывную деятельность для этого, и он работает хорошо.

Обычно я разворачиваюсь, пока у меня что-то не очистится для выпуска.

В этот момент я создам ветвь с именем нечто вроде release. Я буду прыгать на систему производства и проверить свою недавно созданную ветку.Для нескольких проектов у меня будет промежуточная область, которая работает на производственной системе.

Например, я мог бы иметь дерево каталогов, выглядит следующим образом:

/web/sites/release-1 
/web/sites/release-2 
/web/sites/release-3 
/web/sites/release-4 
/web/sites/stage ==> release-4 
/web/sites/live ==> release-3 

«стадии» и «живой» символические ссылки, и то, что Apache имеет для DocumentRoot для VirtualHosts www.example.com и stage.example.com)

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

Разветвление перед развертыванием, я могу сделать аварийные исправления на производстве в редком случае, мне нужно это сделать. Затем я могу объединить эти изменения обратно в багажник, когда это удобно и целесообразно.

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

в httpd.conf:

<Directory ~ "\.svn"> 
    Order allow,deny 
    Deny from all 
</Directory> 

Answer 2

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

Я использую SVN, который размещается на главный сервер. Есть два сервера, разработка и производство. Я делаю все свое редактирование работы на кассе на сервере разработки, а затем, когда изменения готовы к работе в прямом эфире, я их фиксирую, а затем обновляю проверку на рабочем сервере, который является сайтом в реальном времени.

Answer 3

Mercurial стиль:

> cd ~/code 
> hg init 
> hg add * 
> hg commit -m "Initial checkin" 

Это поможет вам рабочую ртутный репозиторий. Прочтите ссылку для получения дополнительной информации о том, как ее использовать.

Вы можете клонировать с локального веб-сервера и вашего веб-сервера в реальном времени, чтобы поддерживать актуальность.

Answer 4

Чтобы расширить ответ на @ Nathon. Вы хотите:

cd ~/code # this is where your code lives now 
# set your local webserver to run from *this* directory 
hg init 
hg add * 
hg commit -m "Initial checkin" 
hg clone ~/code ~/staging 
cd ~/staging 
# set Unison to run from *this* directory 

Сделайте свою разработку в ~/code, проверив ее на локальном сервере. Обязательно, когда захотите. Когда вы получаете что-то, что работает, пометьте его. Затем сделайте:

cd ~/staging 
hg pull 
hg update your-tag-name 
# run unison. 

У меня складывается впечатление, что вы хотите, чтобы ваш локальный сервер для работы с плацдарма, но это, кажется, как плохая идея, так как вы хотите использовать его, чтобы проверить свою работу, как вы идете вперед , Если вам нужна какая-то среда QA, вы можете запустить второй веб-сервер из стадии, но я бы сделал это только в дополнение к, не в предпочтении, dev.