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