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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

Общее текущее развитие происходит в транке.

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

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

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

Answer 10

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