Стратегии управления исходным кодом - ветвление, пометка, разветвление и т.д.- для веб-приложений
https://stackoverflow.com/questions/156120
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Этот постинг здесь (Как вы управляете ревизиями базы данных в проекте среднего размера с филиалами?) заставил меня задуматься, как лучше всего работать над веб-проектом, используя ветвление и развертывание в dev, staging и production (вместе с локальными копиями).
У нас нет "релизов" как таковых:если функция достаточно велика, чтобы быть заметной, мы запускаем ее в режиме реального времени (после необходимого тестирования / и т.д.), В противном случае мы загружаем несколько и, когда это кажется "удобным", запускаем их в режиме реального времени.Цель состоит в том, чтобы никогда не проводить развертывание чаще одного-двух раз в месяц или около того, потому что постоянно меняющийся сайт, как правило, вызывает у пользователей некоторое беспокойство.
Вот как мы это делаем, и это кажется немного хрупким (в настоящее время используется svn, но рассматривается возможность перехода на git):
- Две "ветви" - DEV и STAGE с заданным выпуском STAGE, помеченным как TRUNK
- Разработчик проверяет копию TRUNK для каждого изменения и создает для нее ветку
- Разработчик работает локально, часто проверяя код (так же, как и голосование:рано и часто)
- Когда разработчику удобно, что это не полностью сломано, объедините ветку с DEV и разверните на сайте разработки.
- Повторите 3-4 раза по мере необходимости, пока изменение не будет "закончено".
- Объедините ветку изменений с ПРОМЕЖУТОЧНОЙ, разверните на промежуточном сайте.Проведите ожидаемое финальное тестирование.
- По прошествии некоторого периода времени отметьте данную ревизию STAGE как МАГИСТРАЛЬНУЮ и запустите trunk live
- Объединить изменения магистрали обратно в DEV, чтобы синхронизировать их
Теперь, некоторые из этих шагов имеют значительную сложность, от которой можно отказаться вручную, и на практике их очень трудно выполнить (TRUNK -> DEV всегда ломается), поэтому я должен представить, что есть способ получше.
Мысли?
Решение
Ветвление удобно, если вы ожидаете, что работа НЕ будет завершена вовремя, и у вас нет достаточного количества тестов для обеспечения непрерывной интеграции.Я склонен видеть сумасшедшую отраслевую разработку в магазинах, где задачи программирования слишком велики, чтобы их можно было выполнить предсказуемо, и поэтому руководство хочет подождать непосредственно перед выпуском, чтобы определить, какие функции должны поставляться.Если вы выполняете такую работу, то вы могли бы рассмотреть возможность использования распределенного контроля версий, где КАЖДЫЙ рабочий каталог, естественно, является филиалом, и вы получаете всю локальную регистрацию и локальную историю, которую вы можете использовать, никому не причиняя вреда.Вы даже можете осуществлять перекрестное объединение с другими разработчиками за пределами магистрали.
Я предпочитаю, когда мы работаем в нестабильной магистрали с ветвями для кандидатов на выпуск, которые затем помечаются для выпуска и которые затем становятся потоком для экстренных исправлений.В такой системе у вас очень редко бывает более трех ветвей (последняя версия, текущий релиз-кандидат, нестабильная магистраль).Это работает, если вы выполняете TDD и у вас есть CI на нестабильной магистрали.И если вам требуется, чтобы все задачи были разбиты, чтобы вы могли доставлять код так часто, как пожелаете (обычно задача должна длиться всего один-два дня и быть выпущенной без учета всех других задач, составляющих ее функцию).Итак, программисты берутся за работу, проверяют магистраль, выполняют работу, синхронизируются и проверяются в любое время, когда все тесты пройдены.Нестабильная магистраль всегда доступна для ветвления в качестве кандидата на выпуск (если все тесты пройдены), и поэтому выпуск становится не-событием.
В целом, лучшее означает:меньше ветвей, меньше задач, меньше времени на выпуск, больше тестов.
Другие советы
Очевидной мыслью было бы больше "перебазирования" (чаще выполняется обратное слияние со стадии "родительской" среды на "дочернюю" среду "DEV" на ветку разработчика), чтобы минимизировать окончательное влияние TRUNK-> DEV, которое больше не понадобилось бы.
Т.е. все, что делается на ЭТАПЕ, который обязательно будет запущен в производство в одно время (МАГИСТРАЛЬ), должно быть объединено обратно как можно раньше в ветке разработчиков и частных разработчиков, в противном случае эти поздние слияния по модернизации всегда являются проблемой.
НО, если приведенный выше рабочий процесс слияния слишком неудобен, я бы предложил перебазировать ветку, основанную на последней версии сразу после выпуска (new TRUNK).Rebase TRUNK-> DEV станет TRUNK-> REBASE, где решаются все проблемы, затем окончательное слияние DEV-> REBASE, чтобы проверить, что любой текущий dev совместим с новой обновленной системой.Окончательное тривиальное обратное слияние от ПЕРЕБАЗИРОВАНИЯ к DEV (и к частным ветвям dev) завершило бы процесс.
Смысл ветки состоит в том, чтобы изолировать усилия по разработке, которые не могут быть проведены вместе с другими текущими усилиями по разработке.Если TRUNK-> DEV слишком сложен, чтобы работать с текущими разработчиками, его необходимо изолировать.Отсюда и предложение о "ПЕРЕБАЗИРОВАНИИ" ветви.
Мы используем SVN в магазине, в котором я работаю.Хотя мы занимаемся разработкой на C ++, управление версиями довольно универсально.Ниже приведен наш подход, вы можете решить, что из этого, если вообще что-либо из этого, является разумным для вашего подхода.
Для нас ВСЯ разработка происходит в филиале.Мы разветвляемся для каждой ошибки и каждой функции.В идеале, эта ветка посвящена ТОЛЬКО 1 функции, но иногда этого просто не должно быть.
Когда работа завершена, протестирована и "готова", мы объединяем изменения в магистраль.Наше правило заключается в том, что ни в коем случае в магистрали не должно быть взломанного кода.Если поврежденный код попадет в магистраль, его исправление становится приоритетом 1.
Релизы выпускаются, когда все функции готовы и объединены:ветка для выпуска создается так же, как и тег.Тег позволяет нам извлекать shapshot, если нам нужно.Ветка позволяет нам поддерживать нашу предыдущую версию.Исправление ошибок в выпущенной версии выполняется путем перехода к ветке этого выпуска, отходящей от нее.Когда все в порядке, изменения объединяются обратно в ветку выпуска и, при желании, полностью в магистраль.
