Продолжаете ли вы развитие в ветке или в стволе? [закрытый]

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

те люди, которые говорят, что вы будете иметь:

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

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

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

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

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

прочтите статью Мартина Фаулера на Непрерывная Интеграция. Мы свернули нашу собственную такую систему для крупного проекта (3,000 kSLOC) примерно в 2000 линиях Posix sh.

Я склонен использовать подход "release branch". Ствол Летучий. Как только приблизится время выпуска, я сделаю ветку выпуска, к которой я буду относиться более осторожно. Когда это наконец будет сделано, я бы пометил/пометил состояние репозитория, чтобы я знал "официальную" выпущенную версию.

Я понимаю, что есть и другие способы сделать это - это просто так, как я делал это в прошлом.

оба.

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

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

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

Мне нравится и использовать подход, описанный Хенриком Книбергом в контроль версий для нескольких гибких команд. Хенрик проделал большую работу по объяснению как обрабатывать контроль версий в гибкой среде с несколькими командами (работает для одной команды в традиционных средах тоже) и нет смысла перефразировать его, поэтому я просто опубликую "шпаргалку" (которая сама объясняет) ниже:

Мне нравится потому что:

• это просто: вы можете получить его из картины.
• он работает (и масштабируется) хорошо без слишком большого слияния и конфликтов проблем.
• вы можете выпустить "рабочее программное обеспечение" в любое время (в духе agile).

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

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

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

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

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

должно быть ясно, что ветви наследуют все ошибки системы в момент времени, когда она разветвлена: если исправления применяются к стволу, вам придется идти один за другим ко всем ветвям, если вы поддерживаете ветви как своего рода Терминатор цикла выпуска. Если у вас уже было 20 релизов и вы обнаружили ошибку, которая идет что касается первого, вам придется повторно применить свое исправление 20 раз.

ветви должны быть настоящими песочницами, хотя ствол также должен будет играть эту роль: теги будут указывать, является ли код "золотым" в этот момент времени, подходящим для выпуска.

мы развиваемся на стволе, если изменения не слишком серьезные, дестабилизирующие, или мы приближаемся к крупному выпуску одного из наших продуктов, и в этом случае мы создаем временную ветку. Мы также создаем постоянный филиал для каждого отдельного выпуска продукции. Я нашел документ Microsoft на Руководство По Ветвлению весьма полезно. Эрик Синк самоучитель по ветвящимся также интересно, и указывает, что то, что работает для Microsoft, может быть слишком тяжелым для некоторых остальных нам. Это было в нашем случае, мы фактически используем подход, который Эрик говорит, что его команда делает.

Это зависит от вашей ситуации. Мы используем волей-неволей и, как правило, имеем несколько линий развития. Ствол считается "золотым", и все развитие происходит на ветвях, которые сливаются обратно в магистраль, когда они достаточно стабильны для интеграции. Это позволяет отказаться от функций, которые не делают разрез и может обеспечить твердую инкрементную возможность с течением времени, что независимые проекты/функции могут забрать.

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

красота этого в том, что вы можете сделать это рекурсивно: большая ветвь функции может быть своим собственным стволом с другими ветвями, отрывающимися, если это так. Кроме того, финальные релизы получают новую ветку, чтобы дать вам место для стабильного обслуживания.

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

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

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

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

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

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

вам придется экспериментируйте, если у вас есть большая группа разработчиков и получить представление о том, что работает в вашей ситуации. Вот страница от Microsoft, которые могут быть полезными: http://msdn.microsoft.com/en-us/library/aa730834(против.80).аспн

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

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

предыдущие производственные сборки перемещаются в это время в old_production_, а текущий выпуск prod всегда является просто производством. Все, что наш сервер сборки знает о производстве, - это как развернуть производственную ветвь, и мы запускаем эту сборку с помощью триггера force.

мы следуем подходу trunk=current development stream, branch=release(s). На отпуске к клиенту мы разветвляем хобот и как раз держим хобот свертывая вперед. Вам нужно будет принять решение о том, сколько релизов вы готовы поддержать. Чем больше вы поддерживаете, тем больше слияния вы будете делать на исправлениях ошибок. Мы стараемся держать наших клиентов не более 2 выпусков за ствол. (Напр. Dev = 1.3, поддерживаемые версии 1.2 и 1.1).

хобот вообще главная линия развития.

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

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

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

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

под CVS я бы просто работал в "стволе" и никогда не отмечал/ветвь, потому что было действительно больно делать иначе.

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

Я недавно переключился на git. Теперь я обнаружил, что никогда не работаю в багажнике. Вместо этого я использую ветвь песочницы с именем "new-featurename", а затем сливаюсь в фиксированную филиал "текущее производство". Теперь, когда я думаю об этом, я действительно должен сделать ветви "release-VERSIONNUMBER" перед слиянием обратно в "текущее производство", чтобы я мог вернуться к более старым стабильным версиям...

Это действительно зависит от того, насколько хорошо ваша организация/команда управляет версиями и какой SCM вы используете.

• Если то, что дальше(в следующем выпуске) может быть легко спланировано, вам лучше развиваться в багажнике. Управление филиалами занимает больше времени и ресурсов. Но если next не может быть легко спланирован(происходит все время в более крупных организациях), вы, вероятно, закончите сбор вишен(сотни/тысячи), а не филиалы (несколько или десятки).
• С Git или Mercurial управление филиалами намного проще, чем cvs и subversion. Я бы пошел на стабильную методологию ветвей ствола/темы. Вот какой мерзавец.команда git помощью. читайте:http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• С Subversion я впервые применил методологию разработки в магистрали. Там было довольно много работы, когда дело дошло до выпуска, потому что каждый раз, когда мне пришлось выбирать коммиты(моя компания не хорошо планирование.) Теперь я своего рода эксперт в Subversion и довольно хорошо знаю о ветвях manaing в Subversion, поэтому я двигаюсь к стабильной методологии ветвей trunk/topic. Это работает гораздо лучше, чем раньше. Теперь я пробую путь, как git.команда git работает, хотя мы, вероятно, будем придерживаться Subversion.

вот дизайн SVN, который я предпочитаю:

• root
  • развитие
    • филиалы
      • feature1
      • feature2
      • ...
    • багажник
  • бета
    • теги
    • багажник
  • релиз
    • теги
    • багажник

все работы выполняются из разработка / магистраль, за исключением основных функций, требующих собственной ветви. После того, как работа протестирована против разработки/Транка, мы объединяем протестированные проблемы в бета-версию/Транк. При необходимости, код тестируется на бета-сервере. Когда мы будем готовы к развертыванию некоторых изменений, мы просто объединяем соответствующие версии в release / trunk и развертываем.

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

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

метод, который мы используем, - это волевой подход, который подробно обсуждается в великой книге Лауры Вингерд:

http://oreilly.com/catalog/9780596101855/index.html

в то время как книга является perforce centric (Wingerd является Perforce product manager), концепции могут быть применены к любому или всем VCS.

волевой подход (и платформа) служил нам очень хорошо. Он используется во многих фирмах (google, Intuit и, как я слышал, Microsoft Само окно.)

книга стоит того, чтобы ее прочитать.

прочитайте это:http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

нет единого ответа на вопрос о Конвенции о подрывной деятельности IMHO.

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

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

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

@Brian R. Bondy: обратите внимание, что это не решение, как только ваша команда достигает определенного количества ppl/задач, обрабатываемых параллельно в проекте.

Как только отдел QA участвует в qa, усилия, необходимые для обеспечения одной установки на каждую ветвь в процессе, просто слишком высоки. Думай SOA / клиенты / серверы/веб-службы / базы данных все из которых должны быть предоставлены в филиал.

этому решению также не хватает интеграции ступень.