Вопрос
Есть ли законная причина НЕ использовать 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:
источник
Я установил CI-сервер на своей работе, который автоматически создает наш установщик, предполагая, что модульные тесты пройдены успешно. Это заняло около одного дня работы, и это спасло меня намного больше, чем с тех пор, как я его настроил.
Если при настройке вашего релиза / установщика / рабочего сайта есть какие-то ручные процессы, вы всегда сэкономите себе и компании время. Это подходит вам, так как из вашего вопроса похоже, что в процессе установки выполняются шаги ручной настройки.
Для справки, смотрите сам Джоэл, рассказывающий о том, как процесс сборки одним кликом спасает вас в краткосрочной и среднесрочной перспективе.
источник
Убедитесь, что у вас есть соответствующие элементы управления регистрацией в SVN. Например, рассмотрим это -
Если кто-то случайно сделает заезд после предварительной стадии, есть риск что-то сломать. Если это контролируется - как в случае с предварительной проверкой, за исключением случаев, когда исправления ошибок запрещены, я не вижу никаких рисков.
Обновление: у вас проблема с ожиданием, если вы не зарегистрировали свои файлы конфигурации. Я не могу предложить какой-либо совет для этого, кроме "Пожалуйста, сделайте, и быстро!"
источник
Кажется, все в порядке, если за пределами хранилища ничего нет. На самом деле, я считаю, что не стоит тратить время на инструменты развертывания в первые несколько месяцев проекта. Потому что будет слишком много развертываний, недостаточно клиентов, чтобы беспокоиться о формальном процессе выпуска.
Но когда проекту исполнится около года, стоит задуматься о вложении средств в инструмент развертывания. Простые причины
Если вы хотите убедить их, попросите их настроить другой сервер для внутреннего тестирования или контроля качества.
источник