Контроль источников: роли и обязанности - лучшие практики

Я ищу "Best Practices", касающиеся ролей и обязанностей, в частности, кто отвечает за слияния из ветвей разработки в магистраль (или основной). В основном я ищу боеприпасы, чтобы помочь моему делу.

Позвольте мне описать то, с чем я сталкиваюсь. Я ведущий разработчик (владелец) конкретного приложения. Наша компания недавно перешла из VSS (где я был администратором базы данных VSS, в которой хранилось мое приложение) в TFS (где у меня есть разрешения только на ветки разработки, созданные нашей командой «Операции»). В предыдущих работах я был администратором TFS, поэтому я знаю, как работать с TFS и MSBuild.

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

1. Я не могу создавать свои собственные ветви. Я должен создать задачу TFS, чтобы член команды «Операции» создал ветку для меня.

2. Я не могу слиться с Main в мою ветку разработки. Я должен создать задачу TFS, чтобы член команды «Операции» выполнил слияние, а затем надеюсь, что он не «наступит» ни на какие изменения в моей команде, так как «опс парень» может или не может быть разработчиком и, безусловно, имеет практически ничего не знает о коде, который он объединяет.

3. Я не могу слиться с развитием в главное. Опять же, я должен создать задачу TFS, чтобы «оперативник» выполнил слияние, надеясь, что он делает это правильно. Затем мне нужно создать еще одну задачу TFS для слияния обратно с моей веткой, чтобы я мог разрешить любые проблемы, возникшие при слиянии Main с не разработчиком.

4. Я не могу создавать или редактировать сценарии MSBuild. Я снова должен работать с командой "ops", которая является новой для MSBuild, поэтому можно выполнять только самые основные задачи сборки. (Забудьте о чем-либо сложном, или небеса запретить пользовательское задание).

5. Я не могу выполнить скрипт MSBuild. Опять же, только команда "ops" может сделать это.

6. Чтобы завершить все это, как правило, это «оффшорный» ресурс, который выполняет запрошенные задачи, поэтому даже если я создаю задачу (ответвление / слияние / сборка) рано утром, она, вероятно, не будет выполнена до этого вечера

Теперь у меня нет проблем с командой операций, которая поддерживает ветки релизов. Поскольку все, что они делают, это (в основном) берут последнюю версию из Main и продвигают ее в ветку релиза; так что, пока «Main» стабилен и готов, ветвь релиза будет хорошей.

Мое мнение таково, что технические лидеры (такие как я) должны отвечать за поддержку транка («Главный») и любое слияние с / из ветвей разработки. Руководитель группы также должен иметь возможность создавать сценарии MS Build для создания и развертывания в среде тестирования интеграции.

Может кто-нибудь направить меня к документу Best Practices, который поможет мне доказать мою правоту? В результате всех моих поисков были обнаружены только передовые практики, касающиеся методов ветвления и слияния, и упоминание ВОЗ не должно упоминать о таком ветвлении / слиянии.

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

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

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

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

Надеюсь это поможет.

Практики, которые я видел:

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

2. Любой может сделать абсолютно все с ветками разработки. Разработчик должен иметь возможность слияния с main в тот момент, когда другой разработчик говорит им, что ему нужно что-то интегрировать в main.

3. Для слияния с основным (интеграция) существует три варианта:

   • Разработчики делают это сами. Они просто обсуждают риски с ведущим разработчиком и тестируют функции соответствующим образом. Это подразумевает, что у кого-либо есть разрешения; если кто-то нарушает правила, его просто ругают, а неправильное изменение отменяется.
   • Другой разработчик делает это после просмотра изменений. Это все еще требует, чтобы у всех были разрешения, чтобы сделать это; правила все еще применяются ведущим разработчиком.
   • Там назначен интегратор, который просматривает и объединяет в основной. Но интегратор является частью команды и должен понимать код. В небольшой команде это будет тот же человек, что и в архитектуре, в более крупном - отдельные, но им нужно тесно сотрудничать.

4. Тот, кто готовит функцию, должен адаптировать скрипт сборки. Но я не уверен, как это работает с TFS; в системах, которые я использовал, скрипт сборки всегда был версионным файлом, поэтому разработчики редактировали его, как и любой другой, и он был интегрирован вместе со всем остальным.

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

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

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

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

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

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