Какой ваш любимый рабочий процесс развертывания веб-приложений с SVN?

Question

В настоящее время мы используем несколько сложную настройку развертывания, которая включает удаленный SVN-сервер, 3 ветки SVN для DEV, STAGE и PROD, продвижение кода между ними с помощью исправлений и т.д.Интересно, что вы используете для развертывания в ситуации с небольшой командой разработчиков?

Answer 1

магистраль для разработки и ветвь (production) для производственного персонала.

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

Либо совершению в багажник триггеров фиксации крючка, что делает SVN экспортировать и синхронизировать с онлайн-сервера Дев URL - адресов, поэтому если сайт stackoverflow.com тогда этот крючок автоматическое обновление dev.stackoverflow.com

Затем я использую svnmerge для объединения выбранных исправлений из trunk в production в моих локальных извлечениях.У меня снова есть VirtualHost на моем локальном компьютере, указывающий на производственную ветку.

Когда я фиксирую объединенные изменения в производственной ветке, снова экспортный хук SVN обновляет производственный (текущий) экспорт, и сайт работает!

Answer 2

Когда я работал в небольшой команде разработчиков (маленькой, имея в виду меня, другого программиста и босса), там царил настоящий хаос.Однако мы обнаружили, что назначение процесса типа "привратник" сработало для нас.

Гейткипером был человек, который проделал большую часть работы над приложением (в данном случае у меня было 2 проекта, которые я разработал с нуля, у него было около 4).

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

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

Answer 3

У меня не было никаких проблем с организацией общих тегов / ветвей / магистралей.

Общая текущая разработка происходит в магистрали.

Поддержание выпуска в рабочем состоянии происходит в соответствующей ветви выпуска.

Изменения в ветке выпуска, которые все еще актуальны для магистрали, объединяются.

Когда новая версия готова к развертыванию, она помечается тегом trunk, затем на основе этого тега создается ветвь.Новая ветвь выпуска передается на сервер параллельно текущей версии.Когда приходит время переключаться, пути жонглируются ("mv appdir appdir.old && mv appdir.new appdir").

Разработчики, поддерживающие производственную версию, затем svn переключают свою рабочую копию на новую ветку или выполняют новую проверку из нее.

Answer 4

Три ветки - это просто дополнительная работа.

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

Answer 5

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

Answer 6

Мы не используем филиалы для размещения материалов, связанных с Интернетом;только для тестирования экспериментальных вещей, которые займут много времени (читать:больше суток), чтобы слить обратно в багажник.Магистраль, выполненная в стиле "непрерывной интеграции", представляет собой (надеюсь) рабочее текущее состояние.

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

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

Answer 7

Магистраль содержит текущую "первичную" базу кода разработки.

Разработчик часто создает отдельную ветку для любого средне- или долгосрочного проекта, которая может перегружать магистральную кодовую базу и мешать другим разработчикам.Когда он будет завершен, он снова сольется с trunk.

Мы создаем релиз с тегом каждый раз, когда запускаем код в производство.Папка в /tags - это просто номер версии.

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

Answer 8

Я настоятельно рекомендую эту книгу (в настоящее время в черновом варианте). Непрерывная поставка, который описывает полный процесс управления поставкой программного обеспечения, основанный на принципах непрерывной интеграции (среди прочих).

Мне сильно не нравится подход к ветвлению и слиянию, поскольку он может стать очень грязным и довольно расточительным, поскольку в конечном итоге вы тратите время на действия, которые на самом деле не приносят никакой новой ценности.Вы уже один раз разработали, протестировали и исправили свой код, зачем создавать ситуацию (копирование кода в другую ветку), которая требует от вас переделывать эту работу?

В любом случае, способ избежать ветвления и слияния - создавать свои развертываемые артефакты из trunk и продвигать созданные артефакты (а не исходные) по мере прохождения тестирования, промежуточной подготовки и т.д.Таким образом, вы на 100% уверены, что то, что вы запускаете в производство, - это то же самое, что вы тестировали.

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

Answer 9

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

Не создавайте разные ветви для разных сред.

Answer 10

Я лично работаю локально (разработка), добавляя / исправляя функции, и когда я думаю, что все готово, я отправляюсь в trunk (производство).На производственном сервере я просто выполняю обновление svn.

Answer 11

Я работаю с ситуацией, аналогичной той, с которой вы сейчас сталкиваетесь.Мне было поручено найти ‘лучшее’ решение, и оно содержало что-то вроде следующего.

Текущая ветвь представляет серверы в их текущем состоянии.

Любая работа по разработке должна выполняться в ветке, которая взята из live.Это может быть получасовая работа для одного человека или годовой проект с участием нескольких команд.Изменения в live могут быть объединены в эти ветви разработки так часто, как вам заблагорассудится.

Прежде чем часть работы выйдет в эфир, изменения из live снова объединяются, и она помечается как потенциальный релиз.Этот выпуск тестируется в промежуточной среде, и если он проходит тестирование, новый live берется из тега.

Можно объединить несколько частей работы в один релиз, если это работает лучше.

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

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

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