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

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

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

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

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

Я не испытал затруднений из-за общей организации тегов/ответвлений/соединительной линии.

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

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

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

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

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

Три ответвления просто походят на дополнительную работу.

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

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

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

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

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

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

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

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

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

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

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

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

Я работаю с аналогичной ситуацией к тому, что Вы в настоящее время имеете. Для меня определили задачу с нахождением ‘better’ решения, и оно выполнило что-то вроде следующего.

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

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

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

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

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

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

Одна из проблем мы имели с системой, как Вы описываете, то, что DEV может стать устаревшим с НАПОМИНАНИЕМ справедливо быстро, таким образом, Вы не разрабатываете против живого, и не легко определить перекрестные зависимости до этапа. Вышеупомянутое решение решает эти проблемы, все еще оставаясь довольно легким.

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

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

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

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