SVN оформить заказ или экспортировать в производственную среду?

Question

В проекте, над которым я работаю, у нас постоянно идет обсуждение среди команды разработчиков - должна ли производственная среда быть развернута как извлечение из репозитория SVN или как экспорт?

Среда разработки, очевидно, является проверкой, поскольку она постоянно обновляется. Для производства я лично проверяю основной ствол, поскольку он облегчает будущие обновления (просто запустите svn update). Однако некоторые разработчики против этого, так как svn создает файлы с группой / владельцем и разрешениями процесса svn (это на ОС Linux, так что эти вещи имеют значение), а также наличие каталогов .svn в рабочей среде они должны быть несколько грязными.

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

РЕДАКТИРОВАТЬ: Возможно, я не был ясен - одно из требований заключается в том, чтобы иметь возможность постоянно иметь возможность вносить исправления в производственную среду. Мы хотим избежать полной сборки (которая занимает гораздо больше времени, чем простое обновление) только для установки критических исправлений.

Answer 1

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

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

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

Answer 2

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

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

Не говорю, что это сработает для всех, но эти две вещи повлияли на мое решение. Желаем удачи в вашем решении.

Answer 3

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

Только мои $ 0,02

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

Answer 7

дай мне посмотреть ..... Инс? для чего это можно использовать?

/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, который является вашей символической ссылкой на предыдущую сборку релиза, а затем просто переместите символическую ссылку из публичной в указатель на ваш новый каталог сборки , в автономном режиме это занимает меньше времени, чем любая из тех вещей, которые я видел, опубликованные здесь, и это также заставляет вернуться НАЗАД БЫСТРЕЕ, если вы не каждый раз f ck p переводите свою базу данных, изменяя таблицы.

Answer 8

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

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

Answer 9

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

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

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

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

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

Чтобы отделить код «для выпуска» от кода «в разработке», я использую ветвление. С Git это действительно просто, поскольку ветвление дешево и быстро.

Answer 10

ЭКСПОРТ

вот и все. У вас нет веских оснований для добавления лишнего мусора в производственную систему.

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