Управление рабочими элементами в MS TFS 2010 Beta1

Потестировал немного систему управления рабочими элементами в TFS 2010, тут небольшой результат моих экспериментов.

Рабочие элементы

Рабочий элементы в TFS – это единица записи в базе данных TFS, которая используется для управления заданиями в проекте TFS. Каждый рабочий элемент описывается набором атрибутов и моделью поведения, с помощью которой можно определить в каком состоянии находится тот или иной рабочий элемент, по какой причине он в этом состоянии оказался и т.д. С помощью набора рабочих элементов (их атрибутов и модели поведения) реализуются уже шаблоны процессов проектов разработки. С TFS поставляется два шаблона процессов:

• MSF Agile для любителей организовать свой процесс на основе гибких методологий. Данный шаблон имеет небольшой набор рабочих элементов, которых в принципе должно хватать для основных задач гибкого процесса, т.е. не нагружать разработчиков «ненужной писаниной», дать им сконцентрироваться на реализации своих задач и обеспечить необходимый уровень работы с требованиями (сценариями использования).
• MSF CMMI применяется в основном для организаций, в которых качество процесса и продукта стоит на первом месте. Этот шаблон уже имеет большее количество рабочих элементов и более сложные модели поведения для них.

 

Таблица 1. Различия рабочих элементов

 

	MSF Agile		MSF CMMI
Рабочие элементы
Модель поведения для задачи
Кол-во полей на форме для задачи	13		25

 

Управление рабочими элементами

Основное управление рабочими элементами в TFS организовано с использованием клиента Tеam Explorer из Visual Studio. Из этого клиента доступны все операции, которые можно выполнять с рабочими элементами, а их немного:

• Добавление рабочего элемента через меню «Team»:

Рисунок 1. Добавление рабочего элемента

• Редактирование атрибутов рабочего элемента через его форму:

Рисунок 2. Изменение рабочего элемента

• Удаление рабочих элементов не реализовано в TFS. Поэтому, если элемент был по ошибке введен или по какой-то другой причине он не нужен в проекте, то его необходимо закрыть с указанием причины такого действия. Однако если удаление недоступно из Team Explorer, то не факт, что нельзя удалить рабочий элемент. Ранее на форумах обсуждалась реализация такой возможности напрямую через базу данных, позже функция удаления рабочих элементов появилась в утилитах Power Tools.

 

Получить доступ к существующим рабочим элементам можно с помощью специальных запросов, которые позволяют выбирать множество рабочих элементов по необходимым признакам. С этими запросами можно выполнять следующее:

• Создавать новые запросы и редактировать существующие. Все запросы используют специальные условия выборки рабочих элементов, которые позволяют гибко организовать доступ к рабочим элементами в необходимом виде.

Рисунок 3. Редактор запросов

• Поддерживаются следующие типы запросов:
  • – обычный список рабочих элементов

Рисунок 4. Обычный список

• – позволяет просматривать рабочие элементы, для которых верно условие выбора запроса, и связанные с ними рабочие элементы.

Рисунок 5. Список со связями

• – выстраивает результат работы запроса в виде дерева рабочих элементов по связям «Родительский/дочерний элемент»

Рисунок 6. Дерево рабочих элементов

• Кроме того, что и в предыдущих версиях TFS запросы в клиенте Tеam Explorer были разделены на командные и собственные, теперь можно организовывать все запросы в отдельные каталоги для более удобной навигации и поиска необходимых запросов:

Рисунок 7. Клиент Team Explorer

 

Связи между рабочими элементами

 

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

1. Родитель (Parent) – связываемых рабочих элемент указывается как родительский для текущего рабочего элемента и родительских связей может только не более одной для одного рабочего элемента.
2. Дочерняя связь (Child) – связываемых рабочий элемент считается дочерним и их может быть любое количество.
3. Предшественник (Predecessor) –т.е. рабочий элемент, который предшествует текущему, используется для организации последовательности реализации задач, требований и т.д.
4. Последователь (Successor) – рабочие элементы, которые следуют за текущим, например, задачи, которые будут выполнены после текущей.
5. Тестирует (Tested by) – используется для указания, каким рабочим элементом будет тестироваться текущий, допустим, каким тестом тестируется функциональное требование.
6. Связанный (Related) – для реализации других связей, которые не относятся к вышеперечисленным.

Рисунок 8. Связи между рабочими элементами

Интеграция с MS Project

 

Интеграция TFS с MS Project позволяет менеджеру проекта свободно себя чувствовать и выполнять свои функции, используя только MS Project. Данная интеграция присутствовала и в ранних версиях TFS, но в ней было несколько но:

1. В виду того, что родительские связи и связи последовательности были реализованы только в 2010 версии, то всю ту структуру задач и их последовательность можно было видеть только в плане проекта. Сформированная структура в MS Project никаким образом не отражалась на рабочих элементах.
2. При импорте рабочих элементов в план не импортировались плановые сроки, а импортировалась только длительность. Т.е. если задача по какой-то причине удалялась из плана, то при последующем ее повторном импорте в план она оказывалась в начале плана.
3. Если суммировать два предыдущим пункта и предположить, что по какой-то причине план был удален, то восстановить его из проекта TFS было уже невозможно. После операции импорта задач в план, все задачи оказывались в начале плана, восстановить вложенность, последовательность и плановые сроки было невозможно.

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

С помощью интеграции можно делать следующее:

• Импортировать рабочие элементы в план. Причем если рабочий элемент имеет дочерние связи, то они будут в автоматическом режиме обработаны и все дочерние рабочие элементы также будут импортированы в план.

Рисунок 9. Выбор рабочих элементов

• Создавать рабочие элементы из плана MS Project. Если новая задача входит в состав какой-то суммарной, то рабочий элемент будет указан как дочерний по отношению к суммарному. Последовательность выполнения также сохраняется в виде связей Предшественник и Последователь.

Рисунок 10. Создание новой задачи

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

Рисунок 11. Решение конфликтов

• Информация о плановых сроках, последовательности выполнения, структуре элементов в плане полностью соответствует информации в проекте TFS.

Рисунок 12. План проекта

Рисунок 13. План в проекте TFS

 

Интеграция с MS Excel

 

Еще одна полезная утилита в составе TFS. Интеграция с MS Excel позволит просто работать с рабочими элементами всем кому нет нужды использовать Visual Studio и MS Project, например, аналитикам.

С помощью этой интеграции можно делать:

• Импортировать рабочие элементы в таблицу с использованием запросов с поддержкой иерархии на основе родительских и дочерних связей:

Рисунок 14. Рабочие элементы в MS Excel

• Обновлять информацию о рабочих элементах на основе сконфигурированного запроса, причем если появляются новые рабочие элементы, то они автоматически добавляются в таблицу:

Рисунок 15. Выбор запроса для импорта и обновления рабочих элементов

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

Рисунок 16. Сообщение об ошибке

• Интеграция позволяет определить тот список полей, который необходимо видеть в таблице:

Рисунок 17. Выбор полей

• С помощью интеграции можно быстро мастером сформировать графические отчеты на основе существующих запросов:

Рисунок 18. Выбор запроса

Рисунок 19. Выбор графических отчетов

Рисунок 20. Результат работы мастера

Рисунок 21. Результат работы мастера

Дополнительно

• Версионный контроль Visual Studio Team System 2010

Версионный контроль Visual Studio Team System 2010

Систем версионного контроля на сегодняшний день уже много, как коммерческих, так и бесплатных (Microsoft VS TFS, IBM Rational ClearCase, SVN и т.д.). И по большому счету, все они решают одни и те же задачи, но каждый немного по-своему. Можно выделить следующие задачи:

1. Обеспечение механизмов безопасного хранения проектных артефактов. Все что ни создается в течение проекта (файл, документ, модель, тестовый сценарий и т.д.) – все это имеет важное значение для проектной команды и потеря любого из этих компонентов крайне нежелательна и может привести к задержкам работ. Поэтому для всего, что команда создает, с чем работает каждый день, должно быть специальное хранилище, которое обеспечит не только хранение файла, но и хранение всей истории развития каждого элемента этого хранилища.
2. Обеспечение механизмов доступа к проектным артефактам. Собственно возможность чтения и изменения всех проектных артефактов. Причем, система должна обеспечить доступ не только к последней версии файла, но и предоставлять возможность просмотра любой ранее созданной версии элемента хранилища, для того, чтоб можно было понять почему было внесено то или иное изменение. И тут же не стоит забывать о разграничении доступа к различным элементам версионного хранилища, т.е. к одному и тому же файлы различные пользователи могут иметь доступ на чтение/запись или только на чтение.
3. Обеспечение параллельного доступа к проектным артефактам. Параллельная разработка – это уже давно стандарт для любой команды разработки ПО. Одновременное изменение одного и того же файла несколькими членами команды и объединение этих изменений с возможностью разрешения конфликтных блоков исходного кода. Использование веток для распределения разработки между внутренними группами или по функционалу, разрешение конфликтных ситуаций при слиянии веток.

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

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

 

Checkin/chekout

Основные функции любой версионной системы (Check in/chek out), описывать которые большой необходимости нет. С этими функциями знаком каждый разработчик, который уже имел опыт общения с «версионниками»:

• Chek out – это изъять на редактирование файл. При этом TFS дает возможность следующих операций при редактировании, которые позволяют избежать конфликтных ситуаций при работе над одним файлом нескольких разработчиков:
  • Эксклюзивное извлечение, т.е. файл может редактировать только тот пользователь, который первый его взял на редактирование;
  • Извлечение только для редактирования, т.е. когда файл могут редактировать несколько разработчиков, но изменения они могут регистрировать только в том случае, если предыдущий до него разработчик зарегистрировал свои. При этом используется проверка на возможные конфликты между внесенными изменениями.
• Check in – вернуть/зарегистрировать сделанные с файлом или группой файлов изменения.

 

Рисунок 1. Взятие на редактирование

 

Аннотирование

Аннотация кода полезная в повседневной практике функция, которая позволяет просмотреть все изменения, проведенные над файлом, на протяжении всей его длительной истории развития. Это позволяет быстро разобраться новым разработчикам или бывалым восстановить в памяти, что было сделано с файлом, и понять, зачем были сделаны те или иные изменения. Например, если проводились какие-то локальные эксперименты, то результаты этих работ можно зафиксировать в комментариях к изменениям. И когда новый разработчик по истечении времени решит заняться подобными, то ему можно выполнить аннотирование кода, увидеть результаты и не заниматься пустой тратой времени.

Рисунок 2. Аннотирование кода

 

Отложить

Еще одна полезная функция, которая означает «отложить текущие изменения». Эта функция полезна в следующих случаях:

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

Рисунок 3. Отложить

 

Ветвление

Говорить, почему использование веток полезно, наверно, лишнее. Используют различные подходы в использование веток:

• По функционалу. Для продукта создается основной поток разработки, в котором будет храниться готовый продукт. Для каждой функциональной возможности создается отдельная ветка. Когда функционал реализован и оттестирован, все изменения переносятся в основной поток.
• По группам разработки. Для каждой группы разработки создается отдельный поток и используется отдельный поток, в котором будет использоваться как основной и с ним будут синхронизироваться все группы. Такой подход полезен, когда в организации большое количество разработчиков или используется географически разделенная разработка.
• По заказчикам. Если в организации есть продукт, который поставляется нескольким заказчикам, и для каждого заказчика формируются отдельные уникальные функциональные возможности, то можно использовать для отдельного заказчика отдельную ветвь.
• И многое другое. С различными видами ветвления можно познакомиться тут: Microsoft Team Foundation Server Branching Guidance.

Ветвление приобрело новые возможности в TFS 2010. Эти возможности связаны с визуализацией иерархии потоков разработки (см. Рисунок 4).

Рисунок 4. Иерархия веток

Кроме общей визуализации теперь доступна визуализация направления изменений между потоками разработки. Такой визуализатор позволяет сделать следующее:

• Проанализировать общий ход изменений и направление слияний между потоками. С помощью инструмента можно увидеть, как проходило слияние между ветками и какие потоки еще нуждаются в объединении.
• Просмотреть свойства каждого набора изменений. Можно увидеть всю необходимую информацию об изменениях, включая дату, пользователя, комментарий и т.д.
• Выполнить сравнение между потоками. Можно увидеть различия между потоками разработки, как в наборе папок и файлов, так и между исходными текстами конкретных фалов.
• Выполнить слияние веток. Простым перетаскиванием изменений между изображениями веток можно выполнить слияние потоков разработки.

Рисунок 5. Просмотр истории изменений

Рисунок 6. Направление изменений

 

Разрешение конфликтов

Когда возникают конфликтные ситуации?

1. Изменение одного файла. При изменении двумя разработчиками одного и того же файла необходимо слияние их результатов работы.
2. Возврат отложенных изменений. После того как разработчик делал операцию «отложить» для того, чтоб выполнить какие-то другие задачи, он через какое-то время возвращает выполненные им ранее изменения. Сделав возврат, он фактически возвращается к предыдущему состоянию своей разработки и продолжает незаконченную работу. И понятно, что то что он сделает для продолжения отложенной работы не должно конфликтовать с тем, что было сделано ранее.
3. Слияние потоков разработки. Когда необходимо объединить изменения двух веток разработки, то конечно также будут возникать конфликты.

Большинство всех конфликтных ситуаций TFS попытается решить автоматически, но это невозможно во всех случаях. Поэтому в состав TFS включена утилита, которая позволяет решить конфликты в ручном режиме.

Рисунок 7.Список конфликтов

 

Рисунок 8. Ручное слияние

Дополнительно

• Управление рабочими элементами в MS TFS 2010 Beta1

Адаптируем процессы TFS под свои потребности

Хоть Microsoft Visual Studio Team Foundation Server и поставляется с готовыми шаблонами процессов, но удовлетворить они могут не всех. Для новых и молодых команд в принципе стандартный набор шаблонов процессов TFS может покрыть все потребности процесса разработки, особенно для команд использующих гибкие (Agile) подходы к разработке. Некоторые при внедрении TFS стараются приспособиться под то, что имеется, и в некоторых случаях это проходит. Но приспособиться под стандартные шаблоны TFS не всегда представляется возможным, да и не всегда правильно. Ведь у каждой компании есть свои сложившиеся традиции в разработке, своя культура производства ПО, которые описывают текущие процессы разработки ПО в компании. Применив существующие стандарты к процессам компании можно получить некий гибрид процесса разработки, который будет наиболее подходить для компании. В этой статье мы постараемся объяснить, как можно реализовать такие нестандартные процессы с помощью шаблонов TFS.

Читать далее>>

В помощь требованиям TFS

Управление требованиями в TFS стандартными средствами процесс не особо тривиальный. Для управления требованиями можно использовать два подхода: 

1. Использование студии, которая дает полный доступ ко всем свойствам требований через использование специальных запросов. Но работать в студии не совсем удобно и наглядно.
2. Использование интеграции с MS Excel – это самый подходящий метод и его обычно хватает для небольшой команды. MS Excel позволяет гибко настроить соответствие между таблицами и полями требований, вести статистику по работе над требованиями, но, к сожалению, открыть форму требования, чтоб увидеть всю необходимую информацию, невозможно.

Что уже говорить о тех, кто попробовал IBM Rational RequisitePro или Telelogic Doors, которые позволяют не только формировать требования, но и прослеживать трассировку между требованиями, формировать документацию и т.д. Порыскав по интернету, я наткнулся на один интересный инструмент от TeamSolutions, который называется TeamSpec.

Читать далее >>

Экспресс-обзор Microsoft Visual Studio Team System 2010 B1

Что нового в MS VS Team System Beta 1 2010

View more OpenOffice presentations from Александр Шамрай.

 

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

Администрирование

Очень приятно, что появилась наконец-то с третьей версии TFS какая-то консоль управления общими настройками сервера. Т.е. теперь уже отпала необходимость бродить по xml-файлам в поисках необходимой опции. Что там появилось? Там появились настройки нотификации и ……. много чего с чем еще необходимо разбираться, а может и не стоит, т.к. мне кажется, что все, что там находится, скорее всего, будет настраиваться один раз и редко когда трогаться. Что-то также появилось и по мониторингу состояния сервера, но мало чего полезного, на мой взгляд, для управленца или разработчика.

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

1. Если проектируется большая система, которая содержит большое количество подсистем, то конечно было б полезно иметь один большой портал проекта, который объединял бы общие концептуальные требования, возможности системы, какие-то крупные общие итерации и использовался как единый и общий отчетный и синхронизирующий источник.
2. Понятно, что если TFS используется в организации и формируется какой-то собственный процесс разработки, то плодить этот процесс потом для каждого нового проекта нет смысла, что пока, к сожалению, делается в 2008 версии. В 2010 можно по идее сформировать один общий портал процесса, в который уже можно вносить изменения и они будут доступ сразу для всех проектов разработки.

Версионный контроль

Ну что можно придумать еще для версионной системы, ну по большому счету он в текущей версии TFS итак покрывает все потребности. Но все таки пользователи долго и нудно просили сделать разработчиков TFS визуализацию истории и иерархии версионных елементов. Но  для того, чтоб появилась эта  функция нужно из бранча сделать бранч. Да, да, именно так…… смысла чего я так и не понял. Т.е. Вы сначала делаете какому-то каталогу бранч, а потом необходимо сделать «convert directory to branch». Ну, будем надеяться, что это в процессе дальнейшего развития продукта как-то трансформируется или Microsoft даст этому какое-то логическое объяснение.

Управление проектами и рабочие элементы

Ну тут на мой взгляд произошла просто революция. Если ранее TFS в принципе был удобен для небольших и средних команд, которые очень любят Agile методологии и не любят писать толпу документации, то теперь можно со смелостью говорить – TFS 2010 съедобен всем и с любым качеством процесса. Теперь связи между рабочими элементами получили смысл, т.к. раньше это были просто связь элемента с элементом непонятно для чего. Что нового появилось:

1. Связи типа родительская и дочерняя запись – позволяет разбивать одну задачку на несколько и знать какая из какой выросла и не только. Теперь менеджер проекта может импортировать к себе в план требования, которые были разработаны аналитиком, и на основе них планировать работу, декомпозировать на задачи и т.д., при этом получать корректную информацию сколько было ресурсов потрачено на реализацию требований. А если реализованная задача была разработчиком привязана к конкретному чейнжсету, то можно получить даже информацию о том, что было конкретно написано для реализации требования;
2. Связи для отражения последовательности выполнения задач – необязательная, но очень приятная функция. Если б можно было б завязать эту связь на триггера рабочих элементов, т.е. типа «вы уверены, что вы хотите открыть задачу, ведь предыдущая еще не выполнена?» это было б замечательно;
3. Связь с версионной системой приобрела тоже несколько приятных дополнений. В новой версии можно не только привязаться к чейнжсету, который был сделан разработчиком при реализации задания, но и к конкретным элементам версионной системы, а что еще лучше к конкретным версиям элементов версионной системы;
4. Кроме того появилась связь типа «оттестированно», т.е. можно для рабочих элементов типа требований «прикручивать» набор тестов, который сделан для тестирования конкретного требования.

Появилось очень полезное дополнение в интеграцию с MS Project – она наконец-то работает. Если кто помнит, а может и знает, – получить план из набора готовых и спланированных рабочих элементов в TFS для MS Project было невозможно. Теперь интеграция отлично работает и вверх, и вниз, и направо, и налево, корректно сохраняет и импортирует все виды связей, которые реализованы в TFS 2010. Чего еще не хватает, на мой взгляд, – это простой и полезной функции «показать форму текущего рабочего элемента», ведь не вся полезная информация (описание, история и т.д.) может быть импортирована в план.

Тестирование

Еще один существенный прыжок, который был сделан в это версии, – это тестирование. Для тестировщиков появился абсолютно новый инструмент для управления тестами:

1. Инструмент позволяет создавать пакеты тестов, которые можно привязать к конкретным требованиям, и позволяет выполнять эти пакеты тестов;
2. Инструмент поддерживает два вида тестов:
   1. Ручные тесты – это простой набор шагов и их ожидаемых результатов. При выполнении таких тестов можно записать все действия, которые делает тестировщик при тестировании системы;
   2. Автоматические тесты – это программируемый набор тестов, который позволяет записать сначала действия пользователя в системе, а потом выполнить их модификацию для создания контрольных точек и т.д.
3. Инструмент позволяет накапливать детальную информацию о результатах выполнения тестов с записью выполненных действий.

 

Итог

Как мы видим, чем глубже происходит внедрение TFS внутри компании Microsoft, тем все точнее указывают свои внутренние разработчики на те узкие места и «мазоли», которые все еще присутствуют в TFS 2008. Инструмент покрывает все больше потребностей процесса разработки и уже не только «наступает на хвост», но и смело топчется по спине своих главных конкурентов. Откровенно говоря, TFS 2010 приятно удивил, и теперь остается ждать стабильный релиз Microsoft Visual Studio Team System и Team Foundation Server 2010. А на очереди у меня теперь будет более развернутая статься о том чем может пригодиться сей инструментарий в процессе разработки .

Дополнительно:

• Версионный контроль Visual Studio Team System 2010
• Управление рабочими элементами в MS TFS 2010 Beta1

Порядок взаимодействия клиента с TFS Proxy

Перевёл небольшую статейку How Team Foundation Server Proxy 2008 works, которая описывает последовательность действий при взаимодействии клиентского рабочего места TFS Proxy.

Взаимодействие

Ниже описан порядок взаимодействия клиента, сервера и кеширующего прокси, когда пользователь пытается получить файл из версионного контроля:

1. Клиент проходит аутентификацию на сервере.
   1. Сервер обрывает подключение, если аутентификация не прошла. Выход.
2. Клиент посылает запрос на получение файла на сервер.
3. Сервер проверяет права на чтение клиента к файлу.
   1. Сервер отвечает «file does not exist», если клиент не имеет прав на чтение к файлу. Выход.
4. Сервер посылает ответ на загрузку файла клиенту.
5. Клиент передает полученный ответ кеширующему прокси и ожидает файл.
   1. Если кеширующий прокси не возвращает файл через определенный промежуток времени, клиент использует полученный ответ, чтоб получить файл напрямую с сервера. Выход.
6. Кешируюший прокси проверяет наличие файла в кеше.
   1. Если файл уже существует в кеше, то кеширующий прокси возвращает его клиенту.
7. Кеширующий прокси с помощью сервисной учетной записи проходит аутентификацию на сервере.
   1. Сервер обрывает соединение, если аутентификация не проходит. Кеширующий прокси сообщает клиенту об ошибке, и клиент пытается получить файл напрямую с сервера. Выход.
8. Кешируюший прокси запрашивает размещение сервисов версионного контроля.
9. Сервер проверяет наличие прав на чтение серверной информации учетной записи кеширующего прокси.
   1. Сервер обрывает соединение, если таковые права отмутствуют. Кеширующий прокси сообщает клиенту об ошибке, и клиент пытается получить файл напрямую с сервера. Выход.
10. Сервер передает ответ кеширующему прокси о размещении сервисов версионного контроля.
11. Кеширующий прокси скачивает файл, используя информацию клиента полученную на шаге 5.
12. Кеширующий прокси сохраняет файл в локальном кеше.
13. Кеширующий прокси возвращает файл клиенту. Выход.

Примечания

1. Сервер всегда проверяет права на чтение для клиента, а не для учетной записи кеширующего прокси.
2. Сервер всегда проверяет права на чтение серверной информации для учетной записи кеширующего прокси и это единственные разрешения, который должны быть у этой учетной записи.

Другими словами

1. Кеширующий прокси и сервер связаны на серверном уровне, а не на уровне проектов.
2. Кеширующий прокси действует не вместо сервера, а  используется только для кеширования файлов.
3. Учетную запись для кеширующего прокси можно просто добавить в группу доступа серверного уровня, например «[Server]\Proxy Service Accounts», без всяких дополнительных конфигураций безопасности. Это фактически обеспечивает доступ на чтение учетной записи к серверной информации.
   1. Можно добавить учетную запись в группу администраторов, в группу сервисов сервера или проектную группу, что тоже обеспечит доступ у серверной информации. Но этот метод не рекомендуется, т.к. обеспечивает учетной записи больше прав, чем необходимо.

Статья: Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Опубликована новая статья:

Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational: Не секрет, что инструментов автоматизированного функционального тестирования приложений в продуктах семейства Microsoft Visual Studio 2005/2008 не поставляется. Все функциональное тестирование, которое можно выполнять с использованием этих продуктов, это только ручное тестирование. В данной статье рассматриваются возможности автоматизации функционального тестирования для Microsoft Visual Studio с использованием инструментов IBM Rational.

Читать далее >>

Коллективная разработка с использованием Visual Studio Team Foundation Server

На сайте СМ-Консалт и на блоге опубликовал руководство по Team Foundation Server:

• Глава 1 – Введение в среду для коллективной разработки: Представлена архитектура TFS и основные схемы развертывания.
• Глава 2 – Архитектура Team Foundation Server: Представлена архитектура TFS и основные схемы развертывания.
• Глава 3 – Структурирование проектов и решений в системе контроля версий: Описываются различные варианты структурирования файлов решений и проектов Visual Studio, подходящие для коллективной разработки.
• Глава 4 – Структурирование проектов и решений в системе контроля версий Team Foundation Server: Рассказывается о структурах каталогов, подходящих для коллективной разработки проектов различных размеров и уровня сложности
• Глава 5 – Выбор стратегии ветвления и слияния: Описывает стратегии ветвления и слияния для ряда типовых сценариев.
• Глава 6 – Управление зависимостями системы контроля версий в Visual Studio Team System: Рассматривается, как следует обрабатывать зависимости внутри и между решениями Visual Studio.
• Глава 7 – Team Build: Описывается использование Team Build для автоматизации процесса сборки.
• Глава 8 – Как настроить процесс непрерывной интеграции с помощью Team Build: Рассматривается, как можно настроить процессы непрерывной интеграции с помощью Team Build и Microsoft Visual Studio Team Foundation Server (TFS).
• Глава 9 – Настройка плановых сборок в Team Build: рассматривается возможность настройки плановых сборок с помощью Team Build и Microsoft Visual Studio Team Foundation Server (TFS).
• Глава 11 – Управление проектом: Данная глава знакомит с возможностями управления проектами, предоставляемыми Visual Studio Team System, и рассказывает, как с их помощью можно решать многие проблемы и задачи, обычно возникающие при управлении проектами по разработке программного обеспечения.
• Глава 12 – Рабочие элементы: Данная глава знакомит с рабочими элементами и объясняет, как использовать их для управления проектами по разработке ПО.
• Глава 13 – Шаблоны процессов: Объясняется роль шаблонов процессов в Microsoft Visual Studio® 2005 Team Foundation Server (TFS).
• Глава 14 – Проекты MSF Agile: Данная глава поможет лучше понять принципы работы шаблона процесса и руководства по процессу MSF Agile.
• Глава 15 – Создание и отображение отчетов: Описывается архитектура системы создания и отображения отчетов TFS и стандартные отчеты, которые могут использоваться с новыми проектами.
• Глава 16 – Развертывание Team Foundation Server: Рассматриваются основные подходы к развертыванию Microsoft® Visual Studio® Team Foundation Server (TFS) и ключевые решения при развертывании TFS в организации.
• Глава 17 – Обеспечение доступа к Team Foundation Server через Интернет: Данная глава объясняет, как обеспечить удаленный доступ к TFS через Интернет.
• Глава 18 – Что нового в Visual Studio 2008 Team Foundation Server: Представляются новых возможности и функции Microsoft® Visual Studio® Team System 2008 Team Foundation Server .
• Рекомендации: Team Build
• Рекомендации: Управление проектами
• Рекомендации: создание и отображение отчетов
• Рекомендации: система контроля версий
• Краткие практические рекомендации: Team Build
• Краткие практические рекомендации: управление проектами
• Краткие практические рекомендации: создание и отображение отчетов
• Краткие практические рекомендации: система контроля версий

Семинар «Team System® – идеология и практика использования».

26 февраля февраля наша компания совместно с  Legal SoftWave^TM провели семинар в Санкт-Петербургске о возможностях и практике применения MS VS Team Foundation Server. Семинар занял около 8-ми часов и включал в себя демонстрацию основных возможностей системы.  Ниже приведены презентации, которые использовались в ходе семинара.

Презентация	Наименование доклада	Докладчик
Tfs Overview And Architecture (www.cmcons.com) View more presentations from Alex Golder.	Архитектура TFS	СМ-Консалт. Александр Шамрай Руководитель отдела перспективных разработок, консультант по технологиям IBM Rational и Microsoft
TFS Work Item Tracking (www.cmcons.com) View more presentations from Alex Golder.	Управление проектами и рабочие элементы TFS	СМ-Консалт. Александр Шамрай Руководитель отдела перспективных разработок, консультант по технологиям IBM Rational и Microsoft
TFS Version Control (www.cmcons.com) View more presentations from Alex Golder.	Управление версиями в TFS	СМ-Консалт. Александр Шамрай Руководитель отдела перспективных разработок, консультант по технологиям IBM Rational и Microsoft

Перенос баз данных Microsoft Visual Studio Team Foundation Server

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

1. Установить сервер баз данных TFS на промежуточный сервер

2. Перенести базы данных на рабочий сервер баз данных

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

Примечание: прогодно только для использования на MS VS TFS 2005.

Процедуру переноса баз данных можно разделить на следующие этапы:

1. Остановка служб
2. Перенос баз данных
3. Настройка сервера приложений
4. Настройка Windows SharePoint
5. Настройка SQL Report Server
6. Запуск служб

Остановка служб

Перед переносом баз данных необходимо остановить следующие службы и сервисы:

1. Системные службы Windows через панель администратора системы: TFSServerScheduler, SharePoint Timer Service.
2. Web-сервисы с использованием панели администратора IIS, которые необходимы для работы сервера приложений: TFS App Pool, Report Server.
3. Службу отчетности Reporting Services через  Reporting Services Configuration.

Перенос баз данных

Для переноса баз данных на исходном сервере необходимо сформировать копии баз данных TFS с помощью утилит резервного копирования MS SQL Server 2005. Необходимо сделать копии следующих баз:

1. ReportServer
2. ReportServerTempDB
3. STS_Config_TFS
4. STS_Content_TFS
5. TfsActivityLogging
6. TfsBuild
7. TfsIntegration
8. TfsVersionControl
9. TFSWarehouse
10. TfsWorkItemTracking
11. TfsWorkItemTrackingAttachments

Ну и на следующим шагом соответственно является создание новых баз данных на основе сформированных копий на новом сервере баз данных.

Настройка сервера приложений

Для того, чтоб сервер приложений начал работать с новым сервером баз данных, необходимо использовать утилиту командной строки TfsAdminUtil:

TfsAdminUtil RenameDT ИмяНовогоСервераБазДанных

Настройка Windows SharePoint

Для того, чтоб портал Windows SharePoint работал с новым сервером баз данных, также необходимо выполнить ряд настроек.

1. Во первых, необходимо задать новую конфигурационную базу для портала. Для этого нужно войти в центр администрирования SharePoint Central Administration, перейти на страницу «Server Configuration»-»Set configuration database server»-»Configuration Database», указать наименование нового сервера баз данних и имя базы данных STS_Config_TFS, а также выбрать пункты «Database connection type»-»Use Windows authentication (recommended security level)» и «Connect to existing configuration database«.
2. Во-вторых, нужно установить подключение к базе данных, которая содержит данные для портала. Для этого необходимо удалить старую базу на странице «Central Administration»-»Configure virtual server settings»-»Virtual Server List нажать Default Web Site»-»Virtual Server Settings выбрать Manage content databases»-»Manage Content Databases»-»STS_Content_TFS»-»Manage Content Database Settings» с помощью пункта «Remove content database». Далее нужно выбрать «Manage Content Databases»-»Add a content database» в «Database Information» нужно выбрать «Specify database server settings» и в поле «Database name» набрать STS_CONTENT_TFS. В секции «Database Capacity Settings в Number of sites before a warning event is generated» набрать 9000 и в «Maximum number of sites that can be created in this database» набрать 15000.
3. И на последнем шаге нужно запусть службу Windows с использованием панели администратора SharePoint Timer Service.

Настройка SQL Report Server

Для перенастройки сервера отчетности необходимо:

1. Запустить службу Windows отчетности Report Server.
2. Перейти на конфигурационную страницу Server Status в программе администрирования «Microsoft SQL Server 2005″-»Configuration Tools»-»Reporting Services Configuration» и в разделе «Report Server Status»-»Instance Properties» нажать Start.
3. На странице «Database Setup»-»Database Connection» набрать наименование нового сервера баз данных Team Foundation в поле «Server Name» и нажать Connect.
4. На странице «Windows Service Identity» в поле «Built-in Service Account» должно быть выбрано Network Service и кнопка Apply должна быть недоступна. Для того, чтоб дать доступ серверу приложений Team Foundation к SQL-серверу сервера баз данных Team Foundation, нужно в поле «Built-in Service» выбрать Local Service. Не нужно нажимать Apply, а нужно вернуть значение Network Service в поле «Built-in Service». Когда выбран Network Service и кнопка Apply доступна,нужно Apply.
5. Подключиться по адресу http://localhost/reports и выбрать TfsReportDS. В поле «Connection string» необходимо обновить параметр Data source с новым сервером баз данных Team Foundation. Для этого в поле «Connect using» нужно выбрать Credentials stored securely in the report, обновить имя и пароль пользователя, который использовался для сервисов отчетов, и нажать Apply.
6. Под «SQL Server Reporting Services» нужно нажать Home, выбрать TfsOlapReportsDS и выполнить такие же действия, как и в предыдущем шаге.
7. Далее в командной строке необходимо перейти в директорий «диск:\%ProgramFiles%\ Microsoft Visual Studio 2005 Team Foundation Server\Tools» и выполнить следующую команду: SetupWarehouse.exe -o -s newDataTierServerName -d newTeamFoundationDataWarehouseName -c warehouseschema.xml -ra TFSReportServiceAccount -a TFSServiceAccount, где newDataTierServerName – наименование сервера баз данных Team Foundation, newTeamFoundationDataWarehouseName – наименование базы данных warehouse, TFSReportServiceAccount – пользователь, который используется для служб отчетов, TFSServiceAccount пользователь, который используется для служб Team Foundation Server.
8. Далее на сервере баз данных Team Foundation нужно запустить SQL Server Management Studio. В диалоговом окне «Connect to Server» в «Server type» нужно выбрать Database Engine и нажмите Connect. В «Object Explorer» необходимо открыть Databases-TFSWarehouse и правой кнопкой мыши выбрать dbo._WarehouseConfig, нажамть Properties. На вкладке «Table Properties – _WarehouseConfig» выбрать Permissions.  На «Users or Roles» нажать Add. На «Select Users or Roles» добавить пользователя, который используется для служб отчетов (например, TFSReports) и нажать OK.
9. В SQL Server Management Studio в «Object Explorer» нажать Connect и выбрать Analysis Services. В «Object Explorer» выбрать Databases и правой кнопкой мыши выбрать TFSWarehouse и нажать Process. На «Process Database – TFSWarehouse» нужно нажать OK.
10. Для проверки корректности работы отчетов необходимо на сервере приложений Team Foundation подключиться к  http://localhost/reports, в разделе Contents выбрать проект и в нем отчет.

Запуск служб

Для запуска служб на сервере приложений нужно выполнить:

1. Запустить Web-сервис TFS App Pool на странице управления IIS.
2. Запустить службу Windows через панель администрирования TFSServerScheduler.
3. Далее в браузере на сервере баз данных необходимо перейти по адресу http://localhost:8080/WorkItemTracking/v1.0/ClientService.asmx и выбрать «ClientService»-»StampWorkitemCache»-»StampWorkitemCache»-»Invoke».

На сайте Microsoft доступны подробные инструкции для различных конфигураций переноса http://msdn.microsoft.com/en-us/library/ms404879(VS.80).aspx