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

10

Я ищу "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, который поможет мне доказать мою правоту? В результате всех моих поисков были обнаружены только передовые практики, касающиеся методов ветвления и слияния, и упоминание ВОЗ не должно упоминать о таком ветвлении / слиянии.

Майкл Чатфилд
источник
WHO should be performing said branching/merging.это внутреннее организационное решение. Не совсем то, что мы могли бы помочь вам ...
Яннис
2
Не могли бы вы рассказать нам о предполагаемых причинах такой византийской процедуры? Я предполагаю "соответствие CMM Level N" или "Sarbanes Oxley".
Брюс Эдигер
SOX, но только частично. Когда мы впервые обратились к TFS, разработчики имели доступ к Main и Dev. Но затем «некоторые» разработчики (никто из моей команды) решили просто заняться разработкой в ​​Main, а не в ветке Dev, поэтому теперь все команды наказаны.
Майкл Чатфилд

Ответы:

8

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

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

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

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

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

Уайетт Барнетт
источник
3
+1, я набирал что-то похожее: задокументируйте потерянное время и усилия: пусть лица, принимающие решения, сделают осознанный выбор: стоит ли того, чего они пытаются избежать, с нынешней ограничительной политикой, стоит затрат?
Джейми Ф
Я планирую провести такую ​​встречу, но было бы полезно, если бы я мог показать, что эта политика противоречит отраслевым «лучшим практикам».
Майкл Чатфилд
Попался. Не уверен, что там есть что-то конкретное, но биты управления исходным кодом в The Pragmatic Programmer могут содержать некоторые драгоценные камни. Судя по тому, как это звучит, это было чрезмерной реакцией на плохих разработчиков, а не продуманным политическим решением или политикой. Я согласился бы на сделку, где Ops владеет, сливается с Main. Я также настаиваю на том, чтобы ответственные за обеспечение слияния не нарушали ничего, что, вероятно, приведет к тому, что они выйдут из этого. , ,
Уайет Барнетт
Второй, Джейми, все время, проведенное слиянием или ожиданием слияния, должно быть записано, чтобы у вас были доказательства. Не существует «лучшей практики», подходящей для всех компаний. Я работал в крупной компании, где эту задачу выполняла специальная команда управления конфигурацией. В моей нынешней компании есть специальная команда по управлению релизами, которая не выполняет физическую работу по слиянию с основной, но является логическим владельцем и проводит ее аудит. Но IMHO ops обычно не касается исходного кода.
Софтведа
2

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

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

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

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

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

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

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

Ян Худек
источник
Я был бы всем за «назначенного интегратора», лишь бы он был на самом деле разработчиком в команде. Это маршрут, на который я надеюсь в любом случае; Это небольшая команда (4 человека, включая меня). Надеюсь, я смогу получить доступ к созданию / выполнению сценариев MS Build, для меня было бы глупо создавать сценарии nAnt для развертываний разработки, а затем для команды «ops», по сути, создать тот же сценарий для MSBuild. Но это то, что я сделаю, если понадобится.
Майкл Чатфилд
2

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

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

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

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

Murph
источник
1
Да, изо всех сил стараюсь не быть конфронтационным ... пришедшим от парня, жена которого купила ему футболку с надписью "Я бы с тобой согласился, но тогда мы оба были бы не правы". :)
Майкл Чатфилд
Это абсолютный убийца, когда вы правы (-: И в этом случае трудно утверждать, что вы не ... но вам нужно ваше линейное руководство, если что-то изменится
Murph