Я подрядчик, который недавно начал с фирмы.
Команда состоит из 3 разработчиков, состоящих из 2 разработчиков младшего и среднего уровня, еще один на том же уровне, начинающий в ближайшее время, и я (6 Years xp). Для обоих существующих разработчиков это их первая работа вне университета / колледжа, и у них никогда не было старшего разработчика, который бы контролировал их работу раньше.
Нет явной политики контроля версий. Разработчики выполняют всю разработку на соединительной линии, а затем внедряются в производство непосредственно со своих машин для разработки. Существующая команда не знакома с ветвлением.
Я изменяю все это и представляю CI, тестовые / промежуточные / производственные серверы TDD и т. Д., А также политику контроля версий, чтобы дополнить это.
Система управления исходным кодом - TFS, которую я никогда не использовал раньше. Он настроен как один гигантский репозиторий.
Я записал несколько указателей для них, но есть ли что-то еще, что я должен добавить / изменить, учитывая опыт команды?
Политика контроля версий
Разработка ведется на багажнике
Если предполагается, что изменение займет более недели, то это должно быть сделано в ветви, с регулярными слияниями из магистрали в ветку, чтобы остановить эти два выхода из синхронизации.
Выпуск веток, созданных для производственного кода. Эта ветвь должна содержать только стабильный код. У нас может быть либо одна ветка релиза, которая обновляется из ствола один раз за спринт, либо мы можем создать отдельную ветку релиза для каждой недели.
Если необходимо сделать срочное исправление ошибки, затрагивающее производственный код, то это делается в ветке релиза и сливается обратно в ствол.
Если мы примем стратегию с одной ветвью релиза, то ствол будет объединен с веткой релиза один раз за спринт в конце спринта.
Если мы примем отдельную ветвь для каждой стратегии выпуска, тогда ствол НИКОГДА не будет объединен с веткой Release
В некоторых случаях может потребоваться дважды исправить ошибку на разных ветвях, если ветки слишком сильно разошлись. Если мы делаем короткие спринты, то это не должно случаться слишком часто.
Я планирую иметь три сервера. Тестовая среда, в которой всегда выполняется последний код в репозитории. Промежуточная среда, в которой выполняется новейшая версия-кандидат для подготовки и тестирования кода кандидата на выпуск и целей UAT, а также производственная среда.
Причина, по которой я планирую это сделать, заключается в том, что до сих пор клиент делал только внутреннее программное обеспечение. Новейший проект предназначен для высококлассного медиа-клиента, и я чувствую, что команде необходимо принять модель более профессионального развития, чем та, которую они делают в данный момент.
Например, в данный момент пользователь может позвонить команде с сообщением об ошибке. Разработчики обнаруживают и исправляют ошибку, проводят быстрый тест на глазные яблоки на своих машинах, а затем сразу же начинают работу. Нет автоматического тестирования или что-нибудь.
Оглядываясь назад, я думаю, что ветвь функций - это слишком далеко, и я это уберу.
По сути, это сводится к тому, что а) ветвлений вообще нет), б) ветвь релиза и магистраль, и в) ветвь релиза на релиз и транк.
Я склонялся к последнему. Первоначально я думал, что у меня будет и кандидат на выпуск, и выпуск для одновременной работы на отдельных серверах (UAT / Production), но фактически магистраль является кандидатом на выпуск в любой момент времени, поэтому ветвь релиз склоняется к безумию. Я думал только о том, что если мы не хотим, чтобы наши заинтересованные стороны видели код разработки, нам может потребоваться отдельная ветка-кандидат на выпуск, но YAGNI и все такое .....
Ответы:
Для команды из 3-4 разработчиков вы предлагаете СЛИШКОМ много веток.
Каждая ветка, которую вы создаете, - это дополнительные накладные расходы, которые сопряжены с затратами (время, затрачиваемое на слияние, отслеживание того, что и где и т. Д.). Вы должны убедиться, что выгода от наличия филиала превышает стоимость.
Имейте в виду, что единственное реальное преимущество для ветви - это изоляция кода. Это означает, что вам нужна конкретная причина, чтобы хотеть изолировать код.
Наличие отдельной ветки релиза для каждого спринта безумно. Зачем вам код из одного спринта, выделенный из кода для следующего? Почему бы просто не иметь одну ветку стабильного выпуска, которая переносится с каждым спринтом?
Почти любая нетривиальная новая функция займет в реальном времени как минимум неделю после того, как вы учтете разработку, тестирование разработчика, ежедневные прерывания и другие действия и т. Д.
Кроме того, что такое "регулярное слияние"? Ежедневно? Еженедельно? Каждое слияние занимает много времени - вам нужно убедиться, что целевая ветвь слияния строится и запускается после ваших изменений. В небольшой команде частое слияние - это много накладных расходов.
У нас есть команда из 4 разработчиков, работающих над кодовой базой более 1 миллиона строк, и вот как мы работаем:
Одно главное правило: не проверяйте код, который не создается.
Вот и все. Просто, легко понять, получает необходимую изоляцию (в любое время мы можем создать релизную сборку для любой версии).
Преимущества всех разработок в одной ветке:
источник
Вы записали несколько указателей для них, но вы не объяснили, почему ваш подход лучше, чем тот, который они уже используют . Это может быть проблематично. Если вы в духе «Мы сделаем это по-моему, потому что у меня шесть лет профессионального опыта, а у вас нет» (и, читая ваш вопрос, это выглядит именно так), будьте готовы быть ненавидимыми члены вашей команды, которые попытаются сделать все возможное, чтобы не применять ваши концепции.
Есть ли у них проблема, которую нужно решить? Очень важно , чтобы ответить на этот вопрос , во- первых, потому что либо они на самом деле есть проблема , и будет приветствовать ваши предложения, или они прекрасно работают , как они в настоящее время делают, и вы просто нажав на них свой способ работы , только потому , что вы предпочитаете работать таким образом.
В конце концов, принуждение их использовать ветки может оказать крайне негативное влияние . Работать со стволом легко, особенно в Agile-среде. Разработчик фиксирует изменения в магистрали, в конечном итоге обрабатывая небольшие конфликты, и эти изменения немедленно используются платформой Continuous Integration. С филиалами:
Разработчик должен подумать, где должно быть изменение,
Кто-то должен управлять ветвями и сливаться из веток в ствол,
Слияния между ветвями выполняются реже, чем коммиты, что означает, что кто-то должен иметь дело с конфликтами, которые являются более крупными и более сложными, чем конфликт между двумя коммитами,
Каждый коммит не обязательно попадает в непрерывную интеграцию, которая задерживает информацию, которую разработчики получают о последствиях коммитов (особенно регрессии).
Дело в том, что:
делает вещи еще хуже. Я работал в команде неопытных программистов, где неопытный менеджер решил поиграть с ветками. Это привело к большому ( большому ) потере времени и является именно тем, чего вы хотите избежать для проекта, который имеет крайние сроки.
источник
Как говорит Майнма, будьте осторожны с ветвлением. Вы упоминаете разветвление каждые несколько недель, действительно ли необходимо иметь много разветвлений?
В качестве альтернативы вы можете использовать модель «вытягивания» вместо модели «выталкивания». Если вы используете Git или Mercurial, вы можете сделать так, чтобы сервер интеграции проверял их изменения перед отправкой на центральный сервер. В TFS вы можете сделать что-то подобное, используя закрытые проверки . Таким образом, вы можете пройти валидацию и избежать сложности веток.
источник