Как защитить багажник от разработчиков

Question

Мы используем TFS для нашего кода: транк + ветви для кодирования. В моей команде 6 разработчиков.

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

Как я могу обеспечить защиту ствола и заставить разработчиков создавать новые или повторно использовать старые ветви?

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

Answer 1

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

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

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

Answer 2

Какие "исправления" они вносят в TRUNK? Как правило, вы никогда не должны регистрироваться в TRUNK, а только объединять ...

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

Если это аварийная ситуация , тогда ответвление от TRUNK и создание ветви HOTFIX. Это будет копия того, что находится в производстве.

Пример того, когда вы хотите использовать HOTFIX: Допустим, у вас есть изменения, которые вы хотите внести в производство или QA, но вы не хотите, чтобы будущая работа, проделанная в DEV, вышла из-под контроля, поскольку в ней произошли переломные изменения для среды QA, или, возможно, вы просто хотите быть настолько безопасным, насколько это возможно. возможно, и убедитесь, что только тот код, который вы хотели изменить, вышел из вашего развертывания. Если у вас нет ветки HOTFIX, нажмите TRUNK, выберите «Ветвь» и назовите ее HOTFIX или что-то значимое для вас. Затем внесите изменения в HOTFIX, зарегистрируйте их и разверните из ветви HOTFIX. Тогда HOTFIX будет содержать только две вещи: A. Что находится в TRUNK и B. Ваши одноразовые изменения. Он не будет включать в себя всю дополнительную работу, которую вы не проверили или не протестировали в ветке DEV, и это хорошо.

Answer 3

Имеет ли TFS поддержку для запуска сценариев ловушек, как у Subversion?

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

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

Answer 4

Я буду вторым, что сказал @annakata.Кроме того, я настоятельно рекомендую, чтобы тот, кто отвечает за управление SCM в вашей организации, настроил оповещение о регистрации, которое позволяет вам знать, когда кто-то проверяет код в соединительной линии.Таким образом, вы можете продолжить (с ранее упомянутой крикетной битой, если необходимо) с ответственным разработчиком.

Некоторые другие методы, которые следует учитывать:

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

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

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

• Добавьте последствия (в той степени, в которой ваша организация позволяет).Такие вещи, как фонд пива / пиццы, в который они должны внести свой вклад, когда они облажаются, или забавная шляпа, которую нужно надеть, или даже громкое объявление для всей организации по разработке, когда кто-то регистрируется в багажнике.Он быстро понял смысл.

Answer 5

Вы можете установить разрешения на уровне папки.

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

Для получения информации о настройке разрешений см .: http://msdn.microsoft.com/en-us/library/ms252587.aspx

Answer 6

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