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

Ответ 1

для разработки, а также ветвь (производство) для производства.

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Три ветки просто звучат как дополнительная работа.

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

Ответ 4

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

Общее развитие продолжается в багажнике.

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Для развертывания в производство мы делаем SVN Export to Staging. Когда это удовлетворительно, мы используем простой rsync для развертывания в производственных кластерах.

Ответ 8

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

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

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

Я работаю с аналогичной ситуацией с тем, что у вас есть. Мне было поручено найти "лучшее решение", и оно выполняло что-то в следующих строках:

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

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

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

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

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

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

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