Продолжаете ли вы развитие в отрасли или в багажнике?

Ответ 1

Я пробовал оба метода с большим коммерческим приложением.

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

Лучший метод в целом (по моему опыту): багажник должен быть всегда стабильным.

Вот некоторые рекомендации и преимущества этого метода:

• Кодировать каждую задачу (или связанный с ней набор задач) в своей собственной ветке, тогда у вас будет гибкость, когда вы захотите объединить эти задачи и выполнить выпуск.
• QA должно выполняться на каждой ветке до того, как она будет объединена с багажником.
• Выполняя QA на каждой отдельной ветке, вы точно узнаете, что стало причиной ошибки.
• Это решение масштабируется для любого числа разработчиков.
• Этот метод работает, так как ветвление является почти мгновенной операцией в SVN.
• Отметьте каждую выполняемую вами версию.
• Вы можете разрабатывать функции, которые вы не планируете выпускать на некоторое время, и решить, когда их объединить.
• Для всей работы, которую вы выполняете, вы можете использовать код. Если вы работаете только с багажником, вы, вероятно, будете держать свой код незафиксированным и, следовательно, незащищенным и без автоматической истории.

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

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

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

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

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

Ответ 2

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

Те люди выше, кто возражает, говоря, что у вас будет:

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

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

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

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

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

Прочитайте статью Мартина Фаулера о Непрерывная интеграция. Мы прокатили нашу собственную систему для крупного проекта (3000 кГц) в около 2000 строк Posix sh.

Ответ 3

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

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

Ответ 4

И.

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

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

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

Ответ 5

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

Я люблю его, потому что:

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

Стойка обычно является основной линией развития.

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

Ответ 16

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

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

Ответ 17

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

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

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

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

Ответ 18

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

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

Ответ 19

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

• корень
  • Разработка
    • ветки
      • feature1
      • feature2
      • ...
    • багажник
  • бета
    • теги
    • багажник
  • релиз
    • теги
    • багажник

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

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

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

Ответ 20

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

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

В то время как книга ориентирована (Wingerd - менеджер продуктов Perforce), концепции могут быть применены к любому или любому VCS.

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

Книга хорошо стоит прочитать.

Ответ 21

Прочтите следующее: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Ответ 22

Нет ответа на один размер для ответа на вопрос о соглашении subversion IMHO.

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

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

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

Ответ 23

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

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

В этом решении также не хватает стадии интеграции.