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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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