Представление политики ветвления контроля версий небольшой группе

Я подрядчик, который недавно начал с фирмы.

Команда состоит из 3 разработчиков, состоящих из 2 разработчиков младшего и среднего уровня, еще один на том же уровне, начинающий в ближайшее время, и я (6 Years xp). Для обоих существующих разработчиков это их первая работа вне университета / колледжа, и у них никогда не было старшего разработчика, который бы контролировал их работу раньше.

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

Я изменяю все это и представляю CI, тестовые / промежуточные / производственные серверы TDD и т. Д., А также политику контроля версий, чтобы дополнить это.

Система управления исходным кодом - TFS, которую я никогда не использовал раньше. Он настроен как один гигантский репозиторий.

Я записал несколько указателей для них, но есть ли что-то еще, что я должен добавить / изменить, учитывая опыт команды?

Политика контроля версий

Разработка ведется на багажнике

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

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

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

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

Если мы примем отдельную ветвь для каждой стратегии выпуска, тогда ствол НИКОГДА не будет объединен с веткой Release

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

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

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

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

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

По сути, это сводится к тому, что а) ветвлений вообще нет), б) ветвь релиза и магистраль, и в) ветвь релиза на релиз и транк.

Я склонялся к последнему. Первоначально я думал, что у меня будет и кандидат на выпуск, и выпуск для одновременной работы на отдельных серверах (UAT / Production), но фактически магистраль является кандидатом на выпуск в любой момент времени, поэтому ветвь релиз склоняется к безумию. Я думал только о том, что если мы не хотим, чтобы наши заинтересованные стороны видели код разработки, нам может потребоваться отдельная ветка-кандидат на выпуск, но YAGNI и все такое .....

version-control development-process team-foundation-server

— MrBliz
источник

Вы хотели добавить объяснение, почему выбрали именно этот способ? скажем, аналогично тому, как это делается здесь . Кроме того, вы проверяли «Руководство по ветвлению Microsoft Team Foundation Server» (см., Например, здесь )?

— комнат

Попробуйте это

— gbjbaanb

Имейте в виду, что я использую TFS, а не DVCS, как GIT. Это кажется немного специфическим мерзавцем.

— MrBliz

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

— TafT

Мне неудобно называть это ответом, потому что это слишком основано на мнении, но я с большим успехом убедил людей использовать тег «последний известный добро» (LKG), который является движущимся тегом на стволе, идентифицирующим последнего «благословенного» версия (CCB, тестирование и т. д.). Разработчикам говорят, что выпуски будут производиться из этого тега LKG, а не из заголовка ствола, и, кроме того, они могут свободно использовать любые подходы, которые им подходят в то время. Я обнаружил, что этот шаблон самопроизвольно генерирует ветви функций, когда настало время, без каких-либо предварительных усилий или дополнительной работы над частями разработчиков.

— Корт Аммон - Восстановить Монику

Ответы:

Для команды из 3-4 разработчиков вы предлагаете СЛИШКОМ много веток.

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

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

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

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

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

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

У нас есть команда из 4 разработчиков, работающих над кодовой базой более 1 миллиона строк, и вот как мы работаем:

Основная ветвь, где все разработки сделаны
Одна ветвь на основной выпуск (делается примерно раз в год)

Одно главное правило: не проверяйте код, который не создается.

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

Преимущества всех разработок в одной ветке:

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

— 17 из 26
источник

«Имейте в виду, что единственное реальное преимущество для ветви - это изоляция кода. Это означает, что вам нужна конкретная причина, чтобы захотеть изолировать код». - Как насчет проверки кода? Я думаю, что это хорошая причина, даже с двумя разработчиками.

— BlueRaja - Дэнни Пфлугхофт

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

— 17 из 26

@ 17of26, да. Проверка кода обычно используется в качестве предварительного условия, чтобы быть на главной линии. Таким образом, вы должны каким-то образом показать код до этого: на мониторе, в электронном письме или - во многих настройках - на ветке. Это лучше всего работает с инструментом управления репо, таким как GitHub или gerrit.

— Пол Дрэйпер

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

— 17 из 26

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

— 17 из 26

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

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

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

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

Дело в том, что:

Существующая команда не знакома с ветвлением

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

— Арсений Мурзенко
источник

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

— MrBliz

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

— Арсений Мурзенко

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

— MrBliz

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

— комар

@MrBliz Да, я заметил это (и я думаю, что вы поняли это правильно, если только упустили объяснить причины, подтверждающие это). Просто ни ваш комментарий, ни этот ответ явно не упоминают, касается ли это релиза или функциональных ветвей (или обоих?), Поэтому я прокомментировал, чтобы подчеркнуть разницу . Честно говоря, FWIW - единственное, что мне не нравится в этом ответе

— комнат

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

В качестве альтернативы вы можете использовать модель «вытягивания» вместо модели «выталкивания». Если вы используете Git или Mercurial, вы можете сделать так, чтобы сервер интеграции проверял их изменения перед отправкой на центральный сервер. В TFS вы можете сделать что-то подобное, используя закрытые проверки . Таким образом, вы можете пройти валидацию и избежать сложности веток.

— Mathiasdm
источник

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

— MrBliz

Старые ветки будут удалены в TFS, или, точнее, спрятаны.

— MrBliz