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

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

6.08.2008 16:48:24
11 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

15
26.08.2008 23:45:56
Мне нравится это, но как вы поддерживаете обновления вашей базы данных в соответствии с этим методом?
cgreeno 3.02.2009 01:20:19
код веб-сайта обрабатывает обновления базы данных с URL-адреса администратора, и существует «номер версии» базы данных, чтобы знать, когда обновлять.
Thomas Vander Stichele 6.02.2009 09:41:32

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

2
6.08.2008 16:53:36

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

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

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

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

3
6.08.2008 17:18:58

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

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

3
10.10.2017 23:21:30

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

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

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

1
17.08.2008 18:52:14

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

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

0
26.08.2008 23:50:45

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

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

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

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

1
4.02.2009 06:10:35

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

0
4.02.2009 11:58:30

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

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

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

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

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

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

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

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

0
4.02.2009 13:01:04

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

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

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

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

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

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

3
4.02.2009 14:17:08

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

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

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

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

1
30.04.2010 12:41:39