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

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

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

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

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

6.10.2008 16:31:09
Вы говорите так, будто отказываетесь от ветвления и маркировки производственных выпусков. Почему?
S.Lott 6.10.2008 16:35:26
Я отредактировал свой вопрос для дальнейшего объяснения
Eran Galperin 6.10.2008 16:39:15
Думаю, я не понимаю, что такое «Критическое исправление» и почему к нему не относятся с той же тщательностью и уважением, что и к полной сборке. Или у него такой же уровень качества и ваша сборка занимает ДЕЙСТВИТЕЛЬНО много времени? Я не понимаю проблемы.
S.Lott 6.10.2008 20:41:04
Сборка занимает несколько минут, и я не хочу, чтобы сайт отключался на несколько минут каждый раз, когда я хочу внедрить критические исправления в производство. Я надеюсь, что это проясняет.
Eran Galperin 7.10.2008 01:56:32
Почему сайт переходит в автономный режим? Можете ли вы выполнить операцию «Построить, а затем переместить» из кассы SVN в производственные помещения? если это так, устранит ли это опасность попыток управлять производственными выпусками из магистрали?
S.Lott 7.10.2008 13:01:02
10 ОТВЕТОВ
РЕШЕНИЕ

Кажется, что часто задаваемые вопросы 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.

13
4.08.2009 16:01:21
После дальнейших исследований, кажется, не существует очевидного способа запуска сценария перехвата при создании нового тега.
Chris 4.08.2009 16:07:49
Это действительно стоит посмотреть на: stackoverflow.com/questions/4159104/…
markus 10.10.2011 18:02:37

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

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

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

10
12.04.2009 08:42:35

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

Просто мои 0,02 доллара

9
6.10.2008 16:35:24
Как видите, многие не согласны с вашим утверждением (скорее экспорт, чем оформление заказа). Не могли бы вы объяснить более четко, почему вы так говорите? Я также считаю, что гораздо удобнее иметь возможность обновлять, а не удалять все и экспортировать все заново. Поэтому я ищу хорошие аргументы для экспорта, но не нашел. Единственной проблемой была безопасность, но мне кажется, что .htaccess позаботится об этом хорошо и верно.
markus 10.10.2011 17:57:39

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

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

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

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

8
6.10.2008 16:36:20
Как видите, многие не согласны с вашим утверждением (без вопросов). Не могли бы вы объяснить более четко, почему это не вопрос для вас. Я также считаю, что гораздо удобнее иметь возможность обновлять, а не удалять все и экспортировать все заново. Поэтому я ищу хорошие аргументы для экспорта, но не нашел. Единственной проблемой была безопасность, но мне кажется, что .htaccess позаботится об этом хорошо и верно.
markus 10.10.2011 17:56:50
Во-первых, я всегда делаю веб-приложения вместо веб-сайтов, и я не развертываю файлы кода (собирая их в dll и развертывая в bin). Это намного чище и безопаснее. И так как мои сайты работают таким образом, я абсолютно не хочу подключать SVN и обновлять файлы. Во-вторых, как я уже говорил выше, предпочтительным методом является использование сценариев сборки, поэтому мой процесс - 1) экспорт кода из SVN в местоположение сборки 2) выполнение сценария сборки 3) последний шаг сборки - копирование скомпилированной версии в расположение сайта. Таким образом, независимо от длины сборки, сайт отключается только из-за длины копии файла.
Carlton Jenke 24.10.2011 17:03:08
Спасибо за дополнительные объяснения!
markus 24.10.2011 19:36:26

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

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

2
6.10.2008 16:35:45

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

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

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

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

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

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

1
6.10.2008 20:26:41
20 секунд - это значительное время простоя ... Я не хочу, чтобы сайт отключался на 20 секунд каждый раз, когда я хочу внедрить исправления в производство.
Eran Galperin 7.10.2008 01:58:25
На самом деле, нет. Старый материал все еще там, пока новые файлы копируются. На самом деле, вы даже можете настроить postinstall-скрипт, чтобы настроить все файлы в другом каталоге и просто поменять его на действующий каталог, когда копирование будет завершено. Нет разницы, чем тип развертывания svn export.
Milan Babuškov 7.10.2008 19:55:41

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

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

1
13.04.2010 13:41:02

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

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

1
4.07.2010 18:32:42

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

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

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

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

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

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

1
5.12.2012 17:31:30

ЭКСПОРТ

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

  • Вы выставите свой исходный код
  • Если это веб-приложение, это еще хуже, ваши посетители могут загрузить ваш исходный код, как это круто! очень открытый :)
-3
12.04.2009 08:59:21
Почему и как вы выставляете свой исходный код? У вас обычно нет других вещей, которые вы не хотите показывать посетителям? Вы когда-нибудь показывали посетителям что-нибудь, кроме самого сайта? Вы разрешаете список каталогов вообще? Я никогда. Вот для чего .htaccess.
markus 10.10.2011 18:04:57