Допустимо ли развертывание веб-приложения в производство напрямую из SVN?

11

Вопрос

Есть ли законная причина НЕ использовать SVN для развертывания на производственном уровне, или это просто случай личных предпочтений, и нет никакого реального дела против SVN?

Фон

У меня на рабочем месте есть культура помечать релизы в SVN, а затем развертывать эти выпуски непосредственно на различных веб-серверах, используя svn coили svn switchвключая непосредственно в производство.

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

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

Редактировать:

Что я имею в виду о сборке и развертывании:

Например, если разработчику требуется параметр web.config, добавленный для конкретной среды. Web.config обычно не хранится в svn, поэтому эти файлы обновляются вручную без какой-либо формы сценария автоматической сборки. Поэтому, если они потеряны или OPS забудет добавить поле в файл web.config для выпуска, у вас возникнут проблемы.

Скрипт сборки, который использует XMLPoke для автоматической генерации файла web.config, подходящего для конкретной среды, идеален, поскольку у вас есть версионный скрипт, который документирует все изменения, необходимые для каждой из ваших сред.

Текущий метод сборки и развертывания

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

Миграция базы данных для большинства проектов осуществляется с помощью сценариев БД или сценариев миграции (Migrator.NET) или пакетов CMS.

CI обычно выполняется Team City на основе проверки, у нас есть процесс проверки кода, когда все заявки оформляются в филиалах, а затем проверяются на предмет проверки на правильность и правильность / качество до проверки на соединительную линию (работает хорошо).

Однако фактическое развертывание кода в значительной степени всегда осуществляется через SVN, либо через проверку помеченного выпуска, либо, в более общем случае, коммутатора SVN. Мне странно, что мы используем наш репозиторий как часть процесса развертывания.

Конфигурация обычно не меняется очень часто, единственные вещи, которые будут в конфигурационных файлах, - это информация, специфичная для среды. Все остальное в БД.

Не поймите меня неправильно, это работает, это работает хорошо. Однако я хочу попробовать автоматизировать сборку и развертывание. Я использовал это с Rails и Capistrano, а также для личных проектов, использующих Cygwin, Nant и SSH.

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

Или нет никаких действительных аргументов против использования SVN специально для развертывания в производство?

Джастин Шилд
источник
Можете ли вы уточнить, что «без использования сценария сборки и развертывания или какой-либо формы или автоматического развертывания вы теряете настройки среды интеграции»?
talonx
@talonx - например, если разработчику требуется добавить параметр web.config для определенной среды. web.config обычно не хранится в svn, поэтому эти файлы обновляются вручную без какой-либо формы сценария автоматической сборки. Так что, если они потеряны или OPS забудет добавить поле в web.config, у вас возникнут проблемы. Скрипт сборки, который использует XMLPoke для автоматической генерации файла web.config, подходящего для конкретной среды, идеален, поскольку у вас есть версионный скрипт, который документирует все изменения, необходимые для каждой из ваших сред.
Джастин Шилд
Спасибо. Может быть, вы можете отредактировать свой вопрос, чтобы уточнить этот момент.
talonx
Им просто нужно проверить источники или есть какие-либо ручные действия после проверки (компиляция, упаковка, конфигурация, ...)?
Дэвид

Ответы:

7

Исходя из моего опыта, есть как преимущества, так и недостатки:

Плюсы:

  • Иногда вы производите срочные исправления на рабочем сервере, а затем можете проверить их обратно прямо оттуда. (Хотя теоретически из соображений безопасности всегда полезно использовать доступ только для чтения к репо с рабочего сервера.)

  • Простота: вы выполняете быстро, хотя, как уже упоминалось, переключение на схему сценариев обновления может быть таким же простым.

Минусы:

  • Ваша система может работать нестабильно во время ваших svn upобновлений и обновлений БД. Для сайта с большим трафиком это означает, что некоторые пользователи в лучшем случае будут получать сообщения об ошибках, неработающие страницы или пустые страницы. Ну, это то, что мы очень часто видим в различных социальных службах. Хороший сервис, однако, делает это «атомарно» в том смысле, что переводит систему в режим обслуживания на время обновления. ( Вы сломали Reddit! )

  • Конфликты: разрешение внезапных конфликтов на производственном сервере - ужасная идея: опять же, сервис становится нестабильным, пока вы его исправляете.

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

  • Безопасность: тот, кто получил доступ к вашему производственному серверу, законно или нет, также получает доступ к вашим репозиториям, возможно, к другим продуктам, и, возможно, также с доступом для записи! В целом открытие вашего внутреннего SVN-сервера для внешнего мира - плохая идея. Ваши исходные репозитории должны находиться за брандмауэром компании, точка.

  • В любом случае будут сценарии обновления, например, для обновления структуры БД, управления cronjobs и т. Д., Так почему бы не иметь сценарий, который все это делает? - т.е. извлекает последний предварительно упакованный выпуск, переключается в режим обслуживания, обновляет источники, запускает специфичные для выпуска сценарии и т. д.

Изменить: для тех, кто все еще на схеме SVN, не забудьте это в вашей конфигурации Apache:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>
mojuba
источник
1
+1: отличные аргументы. Возможно, мне удастся продать его с точки зрения безопасности и риска получения скомпрометированного хранилища. Безусловно, веская причина для обсуждения вопроса об использовании SVN для развертывания на производстве.
Джастин Шилд
2

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

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

Для справки, смотрите сам Джоэл, рассказывающий о том, как процесс сборки одним кликом спасает вас в краткосрочной и среднесрочной перспективе.

Bringer128
источник
0

Убедитесь, что у вас есть соответствующие элементы управления регистрацией в SVN. Например, рассмотрим это -

  • Возможности отмечены для релиза
  • Код развернут в стадии подготовки, QA выполняет свою работу
  • Исправлены ошибки, еще один раунд тестирования (однако он работает в вашей команде)
  • То же самое для pre-prod
  • Развернуть в производство

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

Обновление: у вас проблема с ожиданием, если вы не зарегистрировали свои файлы конфигурации. Я не могу предложить какой-либо совет для этого, кроме "Пожалуйста, сделайте, и быстро!"

talonx
источник
Файлы конфигурации отмечены как что-то вроде web.config-default. Самая большая проблема в этом состоит в том, что очень легко забыть обновить версионный файл в SVN, если вы добавляете функции, так как они не требуются непосредственно для развертывания. Эти файлы почти всегда устарели, и только когда вы обнаружите, что вам нужен файл, вы пытаетесь выяснить, что отличается между версионным файлом и не версионным файлом. Кроме того, вы не хотите обновлять версию для каждой среды в SVN по той же причине.
Джастин Шилд
Как насчет выполнения операций всегда берите конфигурационный файл из SVN перед развертыванием?
Талон
0

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

Но когда проекту исполнится около года, стоит задуматься о вложении средств в инструмент развертывания. Простые причины

  • Бизнес растет, поэтому вы планируете разместить его на нескольких серверах
  • Могут быть ошибки в конкретной среде, и у вас нет места, чтобы повторить ошибку. Нет простого способа установить его без процесса tar-untar-забудьте_about_home_for_a_week.
  • Кто-то может сломать сборку. Кто сломал сборку

Если вы хотите убедить их, попросите их настроить другой сервер для внутреннего тестирования или контроля качества.

arunmur
источник