Среда разработки - VCS от разработки до промежуточного сервера и до производства

Вот чем мы занимаемся на работе:

У нас есть промежуточный сервер, на котором запущен Apache, и сервер Subversion. У нас есть ловушка post commit, которая обновляет рабочую копию в каталоге htdocs, таким образом, когда разработчик что-то фиксирует, он автоматически обновляется на промежуточном сервере, чтобы каждый мог видеть последний код.

На производственных серверах клиента (тех, которые мы можем контролировать) у нас установлен клиент Subversion, а веб-сайт является рабочей копией. Когда нам нужно обновить работающий сайт, мы входим в оболочку и запускаем svn up. Если вы сделаете что-то подобное, обязательно ограничьте доступ к каталогам .svn либо с помощью файлов .htaccess, либо из основной конфигурации Apache.

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

Мы никогда, никогда не редактируем файлы через FTP на действующем сайте. В целом мы используем эту установку почти 2 года, и, за исключением случайных конфликтов на промежуточном сервере, у нас никогда не было никаких проблем.

Фактически вы можете установить сервер SVN на свой локальный компьютер, что я бы рекомендовал вместо его установки на веб-сервере (при условии, что вы делаете резервные копии). Проще всего, поскольку его используете только вы, было бы использовать протокол file://, но использование svnserve является немного более надежным и предпочтительным методом, если вы хотите найти время для этого.

@Michael, я не согласен - я бы сказал, что лучше ставить на linux vps, особенно если вы уже платите за услугу хостинга. Мне очень полезно иметь возможность просматривать и загружать материалы из моего репозитория svn, где бы я ни находился, с любого компьютера, на котором я работаю.

@nicky, я начал с svn (и контроля версий) несколько лет назад, и я сделал маленькие шаги, которые упростили задачу.

Если бы мне пришлось сделать это снова, я бы для начала прочитал svn book. Книга написана очень хорошо, и на ее прочтение ушло не более 1-2 дней.

Пока вы читаете, установите svn на свой vps linux с помощью внешнего интерфейса apache.

После этого выберите один из своих веб-сайтов и импортируйте его в svn. Вот как я структурирую свое svn-репо. Например, предположим, что мое репо размещено на http://mysvn.mydomain.com/svn/. :

  mywebsite1
     - trunk
     - tags
     - branches 
  mywebsite2
     - trunk
     - tags
     - branches 

Не беспокойтесь о создании идеальной структуры. Это довольно легко реорганизовать, особенно когда вы только начинаете. После того, как вы импортируете несколько проектов в svn, вы начнете понимать, какие проекты должны иметь свою собственную структуру директорий «trunk / tags / branch», а какие можно комбинировать.

Для создания тестовых сред я делаю именно то, что вы описываете. Я использую сценарии сборки для проверки из svn и загрузки файлов в каталоги, которые сопоставлены с субдоменами, такими как "test.clientsite.com" (я работаю в основном на java и использую ant и maven, но я думаю, что вы можете использовать любой язык сценариев, на котором вы знаком с).

Как только вы привыкнете к управлению версиями, вы больше никогда не вернетесь, удачи!