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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

Имеет ли TFS поддержку для запуска скриптов с крючками, таких как subversion?

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

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

Answer 6

Какие «исправления» они делают в TRUNK? Как правило, вы никогда не должны пройти регистрацию на СТВОЛ, но только объединить ...

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

Если это экстренная помощь, тогда откройте ТРАНК и сделайте ветку HOTFIX. Это будет копия того, что находится в производстве.

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