SVN checkout или экспорт для производственной среды?

Ответ 1

Часто задаваемые вопросы о Subversion, по-видимому, защищает развертывание в качестве проверки, завершенную с помощью скриптов hook-скрипта после фиксации. Они не позволяют Apache экспортировать папки .svn(возможно, хорошая идея), добавив в httpd.conf следующее:

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

Я очень новичок в svn, но, возможно, вы можете запустить hook script при создании нового тега. Таким образом, когда вы будете готовы обновить сайт в реальном времени, вы просто фиксируете свои последние изменения в соединительной линии, создаете новый тег, а script обновляет ваш сайт с помощью обновления svn.

Ответ 2

IMHO вам следует создать ветку/тег, в которой у вас есть (желаемое) подмножество dev env, которое вы используете для производства. Кто-то должен либо поддерживать это вручную, либо автоматически используя скрипты. Затем вы должны экспортировать (а не проверять). Инкрементные обновления не являются проблемой, если вы не меняете файлы в рабочей среде, и вы не хотите, чтобы эти файлы были перезаписаны.

Просто мои $0.02

Ответ 3

Без вопросов - экспорт.

Вы не будете делать обновления, поэтому нет причин для оформления заказа. Вы просто разворачиваете мусор.

Я бы сказал, что любая окружающая среда должна быть только экспортом; вы используете только локальную проверку при разработке. Конечно, мы также используем скрипты сборки, поэтому обновление развертывания так же просто, как запуск script.

Что касается кода разработки, создайте ветки для любой выполняемой работы. Выполняйте транзакцию только для соединительной линии, когда она готова к развертыванию в среде разработки.

Ответ 4

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

• Экспорт не учитывает удаленные файлы (если ваше решение не должно удалять все в каталоге и THEN, что, я думаю, намного хуже). Checkout удалит удаленные файлы.
• Проверка выполняется быстрее. Период. Меньше обновляемых файлов означает меньшее время перехода/перехода, а экспорт вытягивает и перезаписывает ВСЕ, а не только файлы, нуждающиеся в обновлении.

Не сказать, что это сработает для всех, но эти две вещи повлияли на мое решение. Удачи вам в решении.

Ответ 5

Я бы посмотрел в какое-то программное обеспечение для развертывания, такое как Capistrano (это рубиновая программа)

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

Ответ 6

Я использую его как копию. Конечно, не ручной.

Я использую 'make' и 'checkinstall'. Я создаю небольшой файл Makefile, который использует системную команду "install", чтобы скопировать все необходимые файлы в соответствующие каталоги на веб-сервере, и у меня есть preinstall и postinstall shell-скрипты, которые будут выполняться на сервере.

Когда приходит время для развертывания, я запускаю "checkinstall", который создает пакет (RPM, DEB или TGZ, в зависимости от того, на какой дистрибутив Linux я нацелен). Я устанавливаю его с помощью обычных инструментов, предоставляемых менеджером пакетов дистрибутива Linux (rpm, dpkg, pkgtool). Конечно, если вы хотите также отслеживать зависимости, вы можете использовать yum, apt-get и т.д.

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

Это может не соответствовать вашей стратегии "нажимать часто", хотя, если вы используете некоторые вещи, которые нужно компилировать. Однако для работы с скриптами (например, PHP, который я делаю) создание пакета (около 300 + файлов PHP) занимает около 20 секунд на моей машине. И примерно столько же, чтобы установить его на любую целевую систему.

Чтобы отделить код "для выпуска" от кода "in-development", я использую ветвление. С Git это очень просто, так как ветвление дешево и быстро.

Ответ 7

Лично я всегда сомневаюсь в решении этой проблемы, Я предпочитаю не иметь каталогов ".svn" вокруг моей производственной среды, это очень грязно но в то же время экспорт очень утомительный с большими веб-приложениями (особенно, если использовать некоторые сторонние компоненты "как Extjs, FCKeditor и т.д.).

Я думаю, что в настоящий момент нет "убийственных решений".

Ответ 8

Позвольте мне посмотреть..... ln -s? что можно использовать для?

/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/

svn экспортировать в ваши каталоги сборки... скопируйте любые файлы конфигурации из /public, которые являются вашей символической ссылкой на вашу предыдущую сборку релиза, а затем просто переместите символическую ссылку из общедоступной точки в новую директорию сборки, это занимает меньше времени в автономном режиме, чем любая из вещей, которые я видел здесь, и он также делает возврат WAY FASTER, если вы каждый раз не используете свой db каждый раз, изменяя таблицы.

Ответ 9

Вот несколько мнений -

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

Оформить покупку или экспортировать? мой подход... Я определенно использую теги и ветки - опасно присоединять производственный сервер к багажнику и молиться, чтобы никто не запускал svn сразу после того, как кто-то совершил неисправный код в багажник, чтобы посмотреть, что он делает на DEV. У меня есть многоразовый тег (скажем _production и _staging), и в начале моей настройки я проверяю каждый из них на соответствующий сервер. Затем я блокирую весь доступ для изменения содержимого живого и промежуточного сервера. После этого сервер DEV привязан к головке багажника. Когда код достаточно стабилен для QA/staging, мы создаем тег и переименовываем его в _staging, чтобы позволить промежуточному серверу синхронизироваться с ним (script run 'svn up') всякий раз, когда он видит изменения этого тега. Как только мы будем довольны _staging, мы переименуем его в _production и разворачиваем код на живой сервер. Кроме того, вы можете создавать теги/ветки с разными именами и использовать URL-адрес svn switch, чтобы указать сервер на новый тег/ветвь (фиксированная точка). Все вышеперечисленное упрощает развертывание без простоя и, если требуется откат, вы можете быстро переименовать прежний тег архива или использовать "svn switch OLD_URL", чтобы немедленно отменить новые изменения, не беспокоясь о каждом маленьком файле и изменениях в строке.

Разрешения и право собственности Если вы понимаете и знаете, какие разрешения должны быть для файлов, вы можете запустить ваш script после каждого развертывания, чтобы установить CHOWN и CHMOD так, как вы хотите.

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

Изображение на сервере существует ошибка? с .svn, вы можете определить точную версию, на которую она синхронизируется (svn info), а затем проверить, соответствует ли она этому URL (статус sv -u). Затем вы можете создать честную реплику этой установки, проверив те же теги/версии на сервере песочницы, где вы можете безопасно устранить неполадки.

Ответ 10

EXPORT

• Вы откроете исходный код
• Если это веб-приложение, это еще хуже, ваши посетители могут загрузить ваш исходный код, насколько это круто! очень открыто:)