В настоящее время мы используем несколько сложную установку развертывания, которая включает в себя удаленный SVN-сервер, 3 ветви SVN для DEV, STAGE и PROD, продвижение кода между ними через патчи и т. Д. Интересно, что вы используете для развертывания в маленьком dev командная ситуация?Каков ваш любимый рабочий процесс развертывания веб-приложений с помощью SVN?
багажник для разработки, а также ветка (производство) для производства.
На моей локальной машине у меня есть VirtualHost, который указывает на ветку соединительной линии, чтобы проверить мои изменения.
Любое обязательство стволу запускает совершить крюк, который делает экспорт СВН и синхронизации для Дев URL онлайнового сервера - поэтому, если сайт stackoverflow.com этот крючок автоматически обновляет dev.stackoverflow.com
Тогда я используйте svnmerge для объединения выбранных патчей от сундука до производства в моих местных проверках.У меня есть VirtualHost снова на моей локальной машине, указывающей на производственную ветвь.
Когда я совершаю объединенные изменения в производственной ветви, снова крюк экспорта SVN обновляет экспорт продукции (в прямом эфире), и сайт жив!
Простая ветвь ствола содержит самый последний код, затем разрезайте ветку, когда мы идем в прямом эфире. Это, похоже, работает довольно эффективно. Вы можете легко перейти к предыдущей ветке всякий раз, когда текущая ветка, которую вы вырезали для живой системы, терпит неудачу. Кроме того, легко исправить ошибки в ветке, которая в настоящее время живет, и поскольку ветвь эффективно умирает, когда вы разрезаете новую, существует только одна реальная ветка, на которой вам нужно работать (а затем слияние исправлений оттуда живая ветка).
Когда я работал в небольшой команде разработчиков (маленький смысл, другой программист и босс), это был довольно хаотичный беспорядок. Однако мы обнаружили, что для нас было задано задание типа «привратника».
Привратник был человеком, который проделал большую работу над приложением (в этом случае у меня было 2 проекта, которые я разработал с нуля, у него было 4).
В принципе, всякий раз, когда он должен был работать над моими проектами, он уведомлял меня о том, что он работает, я бы удостоверился, что репозиторий был современным и готовым к работе, затем он потянул, изменения, а затем совершить. Он сообщил бы мне, что это было сделано, я бы потянул, построил и развернул. Если произошли изменения в БД, у нас была папка с изменениями DB со всеми скриптами, которые исправили бы БД.
Очевидно, что в нем много дыр, но процесс работал для нас и не позволял нам строить друг над другом.
Три ветви просто звучат как дополнительная работа.
Различия в окружающей среде могут быть связаны с различными версиями соответствующих файлов в багажнике. т. е. database.yml & database.yml.prod. Процесс развертывания должен быть экологически безопасным и просто копировать файлы для среды по умолчанию.
Мы не используем филиалы для создания веб-материалов; только для тестирования экспериментальных вещей, которые займут много времени (читай: более одного дня), чтобы объединиться обратно в багажник. Строка в стиле «непрерывной интеграции» представляет собой (надеюсь) рабочее, текущее состояние.
Таким образом, большинство изменений передается прямо в багажник. Сервер CruiseControl.NET будет автоматически обновляться на машине, которая также запускает IIS, и имеет обновленные копии всех доступных ресурсов сайта, поэтому сайт может быть полностью, тщательно протестирован внутри компании. После тестирования файлы загружаются на общедоступный сервер.
Я бы не сказал, что это идеальный подход, но он прост (и, следовательно, подходит для нашего относительно небольшого персонала) и относительно безопасен, и работает отлично.
Мы используем разветвление выпусков - это, по-видимому, более эффективно для нас, чем ветвление функции, которое мы делали.
Не используйте разные ветви для разных сред.
Магистраль содержит текущую «основную» кодовую базу разработки.
Разработчик часто создает отдельную ветку для любого проекта средней и долгосрочной перспективы, который мог бы шунтировать базовую кодовую базу и мешать другим разработчикам. Когда он закончит, он снова сольется с багажником.
Мы создаем помеченный релиз каждый раз, когда мы выставляем код для производства. Папка в/tags - это просто номер версии.
Для развертывания в производство мы делаем экспорт SVN для постановки. Когда это удовлетворительно, мы используем простой rsync для развертывания в производственных кластерах.
Я лично работаю на месте (разработка), добавляя/фиксируя функции, и когда я думаю, что он готов, я беру на себя багаж (производство). На рабочем сервере я просто обновляю svn.
Работаю с аналогичной ситуацией с тем, что у вас есть. Мне было поручено найти «лучшее» решение, и оно выполняло что-то вроде следующих.
Живая ветка представляет собой серверы в их текущем состоянии.
Любые работы по развитию должны проводиться в ветке, которая берется из живых. Это может быть одночасовая работа на полчаса или многолетний многолетний проект. Как часто, как любимые изменения в жизни, можно объединить в эти отрасли развития.
Перед тем, как часть работы перейдет в живую, изменения с живого снова сливаются и помечены как потенциальный выпуск. Этот выпуск тестируется в промежуточной среде, и если он проходит тестирование, новый живьет берется из тега.
Можно слить несколько частей работы в один выпуск, если это работает лучше.
Это означает, что довольно просто поддерживать ветви развития в актуальном состоянии в режиме реального времени, и если часть работы в разработке отбрасывается, минимальный порядок убирается.
Чтобы перейти от работы над одним проектом к другому, разработчик может просто переключить свою локальную рабочую среду на другую ветвь.
Одна из проблем, с которой мы столкнулись с системой, заключается в том, что DEV может быть устаревшим с PROD довольно быстро, поэтому вы не развиваетесь против живых событий и нелегко определить поперечные зависимости до стадии. Вышеупомянутое решение решает эти проблемы, оставаясь при этом довольно легким.
У меня не было проблем с общими тегами/филиалами/организацией магистрали.
Общая продолжающаяся разработка происходит в багажнике.
Техническое обслуживание выпуска в производстве происходит в соответствующей ветви выпуска.
Изменения в ветви выпуска, которые по-прежнему относятся к магистрали, объединяются.
Когда новая версия готова к развертыванию, она помечена из соединительной линии, затем из этого тега создается ветка. Новая ветвь выпуска проверяется сервером параллельно текущей версии. Когда пришло время переключаться, пути жонглируются («mv appdir appdir.old & & mv appdir.new appdir»).
Разработчики, поддерживающие выпуск продукции, затем svn переключают свою рабочую копию на новую ветку или выполняют новую проверку.
Я настоятельно рекомендую книгу (в настоящее время в грубых срезах) Continuous Delivery, в которой описывается полный процесс управления поставкой программного обеспечения на основе принципов непрерывной интеграции (среди прочих).
Мне сильно не нравится подход ветви и слияния, так как он может стать очень грязным и очень расточительным, поскольку вы в конечном итоге тратите время на действия, которые на самом деле не дают никакого нового значения. Вы уже разработали, протестировали и исправили свой код один раз, зачем создавать ситуацию (копирование кода в другую ветку), которая требует повторной работы?
В любом случае, способ избежать разветвления и слияния состоит в том, чтобы построить ваши развертываемые артефакты из магистрали и продвигать встроенные артефакты (а не источник), когда он проходит тест, этап и т. Д. Таким образом, вы на 100% уверены, что вещь, которую вы вводите в производство, - это то же самое, что вы тестировали.
Если у вас есть разные функции, которые могут быть выпущены в разных расписаниях, изменение вашего подхода к тому, как вы реализуете (сделать функциональность настраиваемой или, еще лучше, модульной), может помочь вам сохранить единый порт для разработки.
Мне это нравится, но как вы поддерживаете обновления базы данных в соответствии с этим методом? – cgreeno 2009-02-03 01:20:19
код веб-сайта обрабатывает обновления базы данных с URL-адреса администратора, а также есть номер версии базы данных, чтобы узнать, когда нужно обновлять. – 2009-02-06 09:41:32