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

Вопрос

Есть ли законная причина НЕ использовать 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 специально для развертывания в производство?

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

Плюсы:

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

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

Минусы:

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

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

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

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

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

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

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

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

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

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

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

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

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

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

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

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

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

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