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

голоса
15

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

Задан 06/08/2008 в 17:48
источник пользователем
На других языках...                            


11 ответов

голоса
15

Ствол для развития, а также филиал (производство) для производства материала.

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

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

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

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

Ответил 27/08/2008 в 00:45
источник пользователем

голоса
3

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

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

Обеспечение выпуска в производстве происходит в соответствующей отрасли выпуска.

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

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

Разработчики, поддерживающие выпуск производства, то SVN переключить их рабочую копию в новую отрасль, или сделать свежее извлечение из него.

Ответил 04/02/2009 в 15:17
источник пользователем

голоса
3

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

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

Ответил 07/08/2008 в 22:35
источник пользователем

голоса
3

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

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

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

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

Ответил 06/08/2008 в 18:18
источник пользователем

голоса
2

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

Ответил 06/08/2008 в 17:53
источник пользователем

голоса
1

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

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

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

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

Ответил 30/04/2010 в 13:41
источник пользователем

голоса
1

Ствол содержит текущее «первичное» кодовое развитие.

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

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

Для развертывания производства мы делаем в SVN Экспортировать в постановщик. Когда это удовлетворительным мы используем простой Rsync раскатать в производственных кластеров.

Ответил 04/02/2009 в 07:10
источник пользователем

голоса
1

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

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

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

Ответил 17/08/2008 в 19:52
источник пользователем

голоса
0

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

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

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

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

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

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

Для изменения от работы на одного проекта к другому разработчику может просто СВН переключить их локальную рабочую среду в другой отрасли.

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

Ответил 04/02/2009 в 14:01
источник пользователем

голоса
0

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

Ответил 04/02/2009 в 12:58
источник пользователем

голоса
0

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

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

Ответил 27/08/2008 в 00:50
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more