В прошлый раз, я писал о создании веток, Опыт использования TFS 2010: (Система контроля.Ветки.Создание) и одном из вариантов их иерархии. В этой части я попытаюсь раскрыть работу с системой контроля и более подробно и остановлюсь на средствах контроля доступа к коду в ветках и политики CheckIn.
Настройка прав над действиями в ветках
И так, следующим шагом будет настройка прав доступа к веткам и запрещения некоторых действий, чтобы код всегда был качественным. Здесь небольшое отступление, такой возможности нет в ClearCase UCM, там существуют лишь некоторая настройка прав, например, такая настройка, как не делать Deliver(Merge в сайтовую ветку или ветку интеграции) если файл находится в check-out, или запретить делать Merge из ветки разработчика в ветку другого разработчика. Но все эти настройки распространяются на всех пользователей. Конечно системный администратор может создать несколько групп с разными правами, но доступна такая настройка только на стороне сервера, и как я уже сказал, не системный администратор этого сделать не сможет.
В TFS2010 же есть возможность настроить права доступа к веткам индивидуально, например, можно разрешить интегратору делать Merge в ветку интеграции и сайтовую ветку, а вот разработчику запретить.
И делать это сможет администратор проекта(например, лидер проекта, или менеджер проекта). Я не буду описывать все возможные опции для установки прав. Я лишь покажу одну из возможностей, например, запретить делать изменения разработчикам в сайтовой ветке и в чужой ветке, и работать только в своей.
Чтобы все изменения сливались в сайтовую ветку через единую точку доступа – Интегратора, который отвечает за качество кода головой. Для этого я создал группу пользователей Integrators и разрешил им делать некоторые вещи над веткой интеграции и сайтовой веткой, всем остальным запретил эти вещи делать, см. Рисунок 1 и Рисунок 2.
Рисунок 1 — Права интегратора над сайтовой и интеграционной веткой
Рисунок 2 — Права разработчиков над сайтовой и интеграционной веткой
Также нужно запретить разработчикам и интегратору лазить по чужим веткам и делать в них изменения, например, я запретил Интегратору делать изменения в ветке разработчика Trollik, см. Рисунок 3 и оставил ему права только смотреть код.
Рисунок 3 — Права интегратора в ветке разработчика
Естественно самим разработчикам lamerok и Trollik нужно поставить полные права доступа на свою ветку. я добился того, что хотел, теперь у нас есть система подчиняющаяся правилам:
- Нельзя изменять код в чужих ветках
- Только интегратор имеет право изменять код в сайтовой и интеграционной ветке
- Всем доступен код на чтение из любой ветки
Политика Check-in
И так, я запретил разработчикам самим сливать свои изменения в сайтовую ветку, а также менять код не в своих ветках. Теперь нужно запретить им делать check-in некачественного кода.
Такой возможности нет в ClearCase, поскольку данная операция относится уже к разделу управления рабочим процессом и не обязана быть связанной с самой системой контроля, однако TFS — это интегрированная система, здесь это делать можно и нужно.
Я всегда должен быть уверен, что даже в своих ветках, у разработчиков код соответствует стандарту качества. Но перед тем как делать настройки, я добавлю пустой проект, чтобы было над чем работать.
После этого можно настраивать политику Check-In. Для этого в Team Explorer, нажатием на проекте, правой копки мыши, выберем Team Project Settings и Source Control, см Рисунок 4.
Рисунок 4 – Выбор настроек политики CheckIn
Нам предоставляется возможность выбрать из 4 вариантов:
- Политика Builds — запрещает делать check-in кода, если имеются ошибки во время сборки (компиляции)
- Политика Code Analysis – запрещает делать check-in кода, если имеются ошибки Code Analysis(также выявятся на этапе компиляции средством Code Analysis)
- Политика Testing Policy – запрещает делать check-in кода, если хотя бы один из тестов из списка закончился неудачно. В большинстве случаев здесь имеются в виду юнит тесты, но ничто не запрещает вам добавить в этот список и системные тесты, например тесты пользовательского интерфейса.
- WorkItem – запрещает делать check-in кода, если разработчик не связал изменения с задачей или багом, или любым другим видом рабочего элемента, который на него назначен.
Я конечно же хочу выбрать все, потому что очень беспокоюсь за качество кода, см Рисунок 5
Рисунок 5 — Политика CheckIn
Последовательно добавлю политику Build и CodeAnalysis. Для Code Analysis, выберу минимальные, рекомендованные Microsoft, я же не зверь, и у разработчиков должно быть хоть какое-то пространство для творчества, см Рисунок 6.
Рисунок 6 — Политика CheckIn Code Analysis
Следующий шаг — мне необходимо добавить политику Testing Policy, здесь ситуация немного сложнее. У нас сейчас нет списка тестов. Нам необходимо его создать. Для начала добавим в файл MyClass.cs. который есть у нас в проекте, простой метод, который возвращает true, если число больше 0 и false иначе, см Рисунок 7.
Рисунок 7 — Метод класс MyClass
После этого мы можем создать тест на метод MyMethod и добавить этот тест в список тестов. Для этого нам надо добавить в солюшен тестовый проект, это просто сделать, встав на солюшен и правой мышкой выбрать меню Add->New Project->Test Project. После этой операции появился файл тестов, и настройки для тестов в списке Solution Items, но файл не содержит ни одно теста или списка тестов, потому что тестов мы еще не создавали, и теперь когда тестовый проект создан, мы можем легко сделать это с помощью правой мыши, встав на метод, см Рисунок 8.
Рисунок 8 — Создание юнит теста
Юнит тест сделался автоматически, и по умолчанию, он не проходит. Кроме того, теперь этот юнит тест попал в файл тестов TestSolution.vsmdi->All Loaded Tests. Однако, нам нужно создать список тестов, который будет запускаться перед каждой операцией сheckin. Создадим такой список, нажав на файл TestSolution.vsmdi, в солюшене. Назовем его TestForCheckInPolitics и затем переместим наш юнит тест в этот список, см Рисунок 9.
Рисунок 9 — Создание списка тестов для политики CheckIn
Теперь когда у нас есть список тестов, необходимо добавить его под контроль. Для этого нужно зачекинить файл с тестами (TestSolution.vsmdi). После этого мы можем добавить его в политику. Для этого выберем Testing Policy в окне показанном на Рисунке 5, укажем файл тестов и список тестов для политики CheckIn, см Рисунок 10
Рисунок 10 — Выбор списка тестов для политики CheckIn
Кроме того, для того, чтобы быть уверенным, что разработчик меняет код только по заданию, установим и последнюю политику — связать CheckIn с рабочим элементом.
После того, как политика CheckIn настроена, попробуем зачекинить наш код. Как видно из Рисунка 11, мы потерпели полное фиаско.
Рисунок 11 — Сработала политика CheckIn
Сработали сразу все политики, попробуем последовательно исправить ситуацию.
Для начала включим CodeAnalysis у проектов солюшена и установим у них правила, такие же как мы устанавливали для политики CheckIn (минимальные, рекомендованные Microsoft), затем сделаем билд, запустим юнит тесты и опять попробуем зачекинить файлы, как видно из Рисунка 12, мы все еще не можем этого сделать, из-за того, что наш тест не проходит и мы не указали связь с рабочим элементом.
Рисунок 12 — Нарушение политики CheckIn
Изменим юнит тест, так чтобы он проходил, и свяжем нашу работу с рабочим элементом, см Рисунок 13.
Рисунок 13 — Связывание с рабочим элементом
Теперь система дала нам зачекиниить файлы и вся команда уверена, что в ветке разработчика всегда находится код, который строится без проблем, и не влияет на работу остальной системы, поскольку прошел все юнит тесты.
Следует заметить, что вы можете обойти политику, поставив галочку Override Policy, но в этом случае вам придется написать причину, а ваш менеджер или лидер проекта получит злобное письмо с описанием нарушения.
Такой процесс не раз выручал команду, от несанкционированных изменений. В начале команда была немного медлительной, поскольку, до этого все делалось на скорую руку, но со временем команда привыкла, и ошибок в разработанном ПО стало намного меньше. Вообще командная разработка, и обмен изменениями в системе контроля версий TFS, это отдельная тема для отдельного поста…
Полезные ссылки:
Командная разработка с использованием Visual Studio Team Foundation Server: Справочник