Как синхронизировать Subversion и удаленный сервер (через FTP)?

Question

Нам трудно поддерживать синхронизацию Subversion и FTP. Иногда мы забываем зафиксировать изменения и просто отправить их на веб-сервер, у нас есть папки .svn, разбросанные по всему веб-серверу, некоторые вещи существуют в одном месте и не существуют в другом и т. Д.

Я хочу потратить время, чтобы исправить это сегодня. Каково решение? Есть ли способ, с помощью которого SVN может быть связан с нашим веб-сервером, чтобы мы могли фиксировать как хранилище, так и веб-сервер через FTP? Стоит ли спрашивать у нашего веб-хостинга какую-то другую систему, которая лучше синхронизировалась бы с SVN-репозиторием? Как мы можем обеспечить синхронизацию хранилища и веб-сервера? Как удалить папки .svn?

Как и в заголовке, как мы можем синхронизировать наш SVN-репозиторий и наш веб-сервер?

Answer 1

Вы бы не хотели вносить изменения в работающий веб-сервер без какого-либо тестирования, не так ли?

Краткий ответ: выполнив новую проверку (предпочтительно на центральном сервере) и скопировав только те биты, которые необходимы для запуска приложения.

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

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

Answer 2

То, что я делаю на своем сервере, это проверка кода на сервере.

Так что вместо того, чтобы использовать ftp для передачи данных на сервер, я просто захожу на него и запускаю svn up. Делая это вручную таким образом, вы получаете несколько преимуществ, в том числе возможность отката в случае глючного кода.

Я бы также рекомендовал использовать систему переноса БД (при условии, что вы используете базу данных). Это позволит вам легко откатить изменения схемы БД, чтобы убедиться, что ваш код продолжит работать в случае отката.

Комбинируя их с инструментом, подобным Fabric или Capistrano , вы получите очень надежную и мощную систему развертывания.

Примечание о DVCS:

Некоторые люди здесь упоминают об использовании распределенного vcs . Вот некоторые из наиболее популярных примеров: git и mercurial (есть несколько других).

Оба они имеют другой способ использования, чем svn, но это не относится к этому вопросу напрямую. Самое большое преимущество, которое вы могли бы получить, это то, что если вы делаете теги для каждого push-запроса к работающему серверу, затраты на это будут минимальными по сравнению с традиционным шаблоном тегов для SVN.

Если вы хотите истечь срок действия с любым из этих GitHub и BitBucket , то оба предлагают бесплатный хостинг репозитория для git и mercurial соответственно.

Как говорится, я большой сторонник использования dvcs, и мои личные предпочтения mercurial .

Answer 3

Springloops делает именно то, что вам нужно. Попробуй. Это SVN в сочетании с FTP. Вы работаете с локальной рабочей копией, затем фиксируете изменения в репозитории, затем через Springloops развертываете их выбранную ревизию на любом сервере (Staging или Production) через FTP.

Answer 4

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

С Тигр :

Это делается постоянно, и это легко сделать, добавив скрипт хука post-commit в ваш репозиторий. Прочтите о скриптах хуков в главе 5 книги. Основная идея состоит в том, чтобы сделать «живой сайт» просто обычной рабочей копией, а затем запустить на нем скрипт-обработчик post-commit 'svn update'.

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

Если серверу необходимо обновить рабочую копию, которой он не владеет (например, ~ / public_html / area пользователя joe), одним из методов является создание двоичной программы + s для запуска обновления, поскольку Unix не будет разрешить запуск скриптов + s. Скомпилируйте крошечную программу на C:

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
    execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
    (const char *) NULL);
    return(EXIT_FAILURE);
}

... а затем chmod + s двоичный файл и убедитесь, что он принадлежит пользователю 'joe'. Затем в хуке post-commit добавьте строку для запуска двоичного файла.

Если у вас возникли проблемы с работой ловушки, см. «Почему не работают ловушки моего репозитория?».

Также, возможно, вы захотите запретить apache экспортировать каталоги .svn / в рабочую копию. Добавьте это к вашему httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Answer 5

Попробуйте http://svn2ftp.com - ни один из большого объема управления проектами, вы можете просто настроить репозитории SVN, которые будут автоматически синхронизироваться с любым количеством учетных записей S / FTP при каждом коммите.

Answer 6

Этот сайт показывает, как настроить Subversion, чтобы делать именно то, что вы ищете. http://www.itforeveryone.co.uk/svn2web.html

Answer 7

Я как раз собирался предложить Springloops, когда прокрутил вниз и увидел предложение Криса. Последние пару месяцев я пользуюсь SpringLoops, и мне это очень нравится.

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

Что мне действительно нравится в этом, так это то, что я вижу, на какой версии у каждого сервера есть страница развертывания в Springloops. И все, что разворачивается через Springloops, вы знаете, что это точно.

Я на самом деле искал решение, которое немного больше, чем просто хранилище SVN ... что-то с интегрированными билетами, вики и хронометражем. Мне очень нравится Bitbucket, но у него нет функции развертывания FTP в Springloops, что, к сожалению, исключает меня. Сейчас я буду придерживаться Springloops, пока другой сервис не сможет предложить FTP Deployment.

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

Answer 8

Лучший способ, который я нашел, - это убедиться, что ничто незафиксированное не может попасть на сервер - это лазейка, которую вы должны сначала исправить.

Затем настройте локальную проверку частей вашего репозитория, которые вы хотите синхронизировать, и используйте rsync для передачи данных на сервер (в этом контексте FTP не очень полезен). rsync позволяет исключать файлы и каталоги, поэтому используйте эту возможность, чтобы убедиться, что каталоги .svn не синхронизируются.

Answer 9

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

Answer 10

Настройка ловушки после фиксации , которая обновляет FTP и использует SVN исключительно для изменений. Таким образом, когда изменения будут зафиксированы, ваш веб-сервер будет обновлен.

Предполагается, что веб-сервер является промежуточным сервером. Подробности смотрите в комментариях.