|
|
-
Уже неоднократно наблюдал ситуацию, когда люди, переходящие на TFS с других программ управления требованиями или дефектами, испытывают трудности с непривычной для них, основанной на двух, а не одном, полях системой статусов - или, как они называются в TFS, состояний. Порой даже "родная" система полностью игнорируется, а вместо нее заводится привычное поле "Status" с привычной же кучей всевозможных значений  Такой подход может сгладить "кривую обучения" в краткосрочной перспективе, но в долгосрочной - имеет ряд побочных эффектов, особенно если в дальнейшем планируется задействовать не отдельные подсистемы TFS, а все возможности продукта в единой связке. В первую очередь, речь идет о подсистеме отчетности и запросах: многие стандартные отчеты и запросы к хранилищу рабочих элементов предполагают использование родной системы управления состояниями, и в противном случае просто не будут работать. С другой стороны, в родной системе состояний нет совершенно ничего "военного" - к ней попросту нужно привыкнуть. В основе лежит несколько простых и логичных принципов: - Весь жизненный цикл рабочего элемента представлен в виде ориентированного графа. Состояния являются его вершинами, а переходы между ними - ребрами:
.jpg) - Количество состояний рабочего элементов должно быть минимальным. В стандартных шаблонах их максимум четыре:
- Proposed - рабочий элемент предложен для рассмотрения, но еще не принят в работу - например, клиент предложил новую функциональную возможность, но команда не будет ее реализовывать в текущей итерации.
- Active - над рабочим элементом ведется работа - например, пишется код.
- Resolved - рабочий элемент готов к проверке или тестированию - например, разработчик написал код и юнит-тесты, и все юнит-тесты проходят успешно.
- Closed - никакие действия над рабочим элементом более не требуются, например, тестирование прошло успешно и функциональность вошла в очередной релиз.
- Минимум состояний компенсируется множеством переходов из одного состояния в другое. Каждый переход представляет собой конкретную причину, по которой рабочий элемент оказался в том или ином состоянии. Например, в состоянии Active находятся как принятые в работу в текущей итерации рабочие элементы, так и те, которые "завалили" проверку или тестирование.
Небольшое количество состояний позволяет легко отслеживать динамику "движения" работы в команде. Например, большое количество рабочих элементов в состоянии Proposed может говорить о том, что либо у заказчика бурная фантазия и он придумывает функциональные возможности быстрее, чем команда в состоянии их реализовывать, либо существует узкое место в процессе утверждения в работу (например, перегружен менеджер проекта или заказчик не отвечает на письма и звонки). А большая очередь из рабочих элементов в состоянии Resolved может означать, что команде не хватает инженеров по тестированию. Разумеется, цифра "четыре" - отнюдь не догма. Бывают случаи, когда большее количество состояний оправдано - например, чтобы отдельно отслеживать требования, которые были успешно проверены на тестовом окружении, но еще не попали в производственную эксплуатацию. С другой стороны, не стоит заводить состояния вида "Verified Fixed" или "Verification Failed" - такие значения, скорее, подходят для поля Reason.
|
-
VS 2008 предоствляет 4 метрики, которые подробно описаны в блоге Code Analysis Team:
http://blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx - Взаимозависимость классов: чем она больше, тем больше вероятность регрессионных дефектов, сложнее писать юнит-тесты и делать рефакторинг;
- Глубина наследования: сложные иерархии классов трудны для понимания, осложняют изучение кода новым членам команды. Обратите внимание, что реализация интерфейсов в этой метрике не учитывается.
- Цикломатическая сложность: опять же, чем она больше, тем сложнее отлаживать и поддерживать код, сложнее тестировать, как следствие - повышается вероятность дефектов;
- Количество строк кода: куда же без них
 На уровне классов позволяет выявлять "раздутые" ("три экрана кода") методы, которые логично разбить на несколько более мелких. Цикломатическая сложность, кстати, при этом может быть небольшой, если много действий выполняются строго последовательно. - Индекс простоты обслуживания: синтетическая метрика, учитывающая, в частности, количество строк кода, цикломатическую сложность и объем Халстеда.
|
-
В TFS можно переименовывать уже существующие области и итерации. Но при этом нужно учитывать, что если в ваших запросах присутствуют условия наподобие "Area Path under ...", где в пути фигурирует название переименованной области или итерации, то такие запросы перестанут работать. Для того, чтобы восстановить работоспособность запросов, откройте их для редактирования и исправьте условия, включающие поля Area Path или Iteration Path. Та же самая ситуация с подписками на события. После переименования области или итерации нужно перепроверить условия и, при необходимости, обновить их.
|
-
Team Foundation Server не был бы столь мощным инструментом, объединяющим все роли в проектной группе, если данные составляющих его подсистем были бы изолированными "островками". К счастью, это не так, TFS предоставляет средства для установления связей между различными артефактами. Об этих связях я и хочу рассказать подробнее. Рассмотрим поподробнее "анатомию" ссылки: - Может быть представлена в виде URI вида vstfs:///<tooltype>/<artifacttype>/<tool-specific id>, где "tooltype" - это идентификатор подсистемы (контроль версий, управление сборкой и т.п.), а artifacttype - идентификатор артефакта (например, "набор изменений"). Естественно, оба идентификатора записываются латиницей, например: vstfs:///WorkItemTracking/WorkItem/16723 или vstfs:///vsversionstore/file/b4e3216.
- Связывает потребителя артефакта с его поставщиком. Например, если рабочий элемент ссылается на набор изменений в системе контроля версий, то подсистема управления рабочими элементами является потребителем, а подсистема контроля версий - поставщиком. Потребитель и поставщик могут ничего не знать друг о друге, что, благодаря подсистеме регистрации поставщиков, потребителей и типов ссылок, обеспечивает расширяемость (об этом немного подробнее ниже).
- Ссылки двунаправленны и имеют "прочтение" в каждую из сторон. В примере из второго пункта, если предположить, что тип рабочего элемента - "Дефект", прочтение в одну из сторон, от рабочего элемента к набору изменений, может звучать как "Исправлен в", а в обратную - "Исправляет".
- Контракты поставщика и потребителя соответственно предусматривают возможность прямых ("дайте мне артефакты с такими-то идентификаторам") и обратных ("ссылаетесь ли вы на артефакты с такими-то идентификаторами?") запросов
С точки зрения TFS SDK ссылки делятся на три класса: - Внешние ссылки. Обеспечивают связь рабочих элементов с другими артефактами, такими, как наборы изменений или результаты тестов.
- RelatedLink: Ссылки на связанные рабочие элементы. С помощью этого класса ссылок можно обеспечить прослеживаемость, например, какие сценарии тестирования покрывают то или иное требование. Фактически, это подкласс внешних ссылок, выделенный для удобства в отдельную категорию как наиболее часто используемый.
- Гиперссылки. Здесь все очевидно - обойдемся без комментариев.
Благодаря расширяемой архитектуре TFS можно создавать собственные типы ссылок и, в случае, если поставщиком или потребителем является подсистема управления рабочими элементами, в нее можно встроить собственный пользовательский интерфейс для выбора артефактов для связи с рабочим элементом. Подробно обо всем этом рассказывается в блоге Naren Datha. И, напоследок - об изменениях в linking API в Rosario: http://blogs.msdn.com/dgorti/archive/2007/09/26/querying-on-workitem-links-through-the-api.aspx
|
-
Существование отдельной редакции Visual Studio для профессионалов по базам данных (VSTE for Database Professionals, также известной среди блоггеров Microsoft как "Data Dude"), сильно омрачало жизнь разработчикам Windows и Web приложений. Дело в том, что в реальности редко когда всеми задачами, связанными с базами данных, занимается отдельный человек. Как правило, на "долю" администратора баз данных (DBA) достается оптимизация запросов и структуры базы, а также поддержка и обслуживание БД, находящейся в производственной эксплуатации. Рутинными же задачами по написанию запросов, хранимых процедур и т.п. занимаются разработчики. Ну а поскольку VSTE for Database Professionals - отдельная редакция Visual Studio, которую можно приобрести только в составе MSDN-подписки, то большинство организаций либо не приобретали эту редакцию вообще (поскольку DBA вполне комфортно себя чувствовали и с привычным инструментарием), либо, в лучшем случае, приобретали в очень ограниченных объемах. Однако, я бы не писал столь подробной предыстории, если бы не замечательные новости - с 1 октября редакции Visual Studio для разработчиков и профессионалов по БД становятся одним продуктом! Подписчики, приобревшие VSTE for Developers + MSDN Premium, равно как и партнеры, которым по условиям партнерской программы полагаются лицензии на эту редакцию, теперь автоматически получают лицензию и на VSTE for Database Professionals. И хотя физически единым продуктом обе редакции станут лишь в следующей версии Visual Studio 2010, уже сейчас подписчики получат доступ к скачиванию инсталляционного пакета. Причем, изменения касаются не только Visual Studio 2008, но и Visual Studio 2005. Остается добавить только одно: МО-ЛОД-ЦЫ!
|
-
В TFS существует возможность разграничения доступа на уровне отдельной области (area) или итерации - это удобно, когда над большим проектом работает несколько, возможно даже распределенных, команд. Тем не менее, полезно знать об одной неочевидной особенности TFS, когда вы создаете новую область или итерацию. Дело в том, что по умолчанию стандартные группы TFS, такие как Readers или Contributors не получают никаких прав доступа к вновь созданной области или итерации, соответственна, она будет недоступна ни вам, ни другим пользователям при редактировании рабочих элементов. Причем, что интересно, в документации (раздел Area-Level Groups and Permissions) написано ровным счетом обратное, но на практике, возможно, только при каких-то определенных условиях, происходит именно то, что описано выше, порождая вопросы в форумах. Поэтому, сразу же после создания, убедитесь, что права доступа настроены следующим образом: Группа Contributors и Build Services - View this node
- View work items in this node (только для областей)
- Edit work items in this node (только для областей)
Группа Project Administrators - View this node
- View work items in this node (только для областей)
- Edit work items in this node (только для областей)
- Create and order child nodes
- Delete this node
- Edit this node
Группа Readers - View this node
- View work items in this node (только для областей)
Подробности в документации: http://msdn.microsoft.com/en-us/library/ms253077.aspx
http://msdn.microsoft.com/en-us/library/ms252587.aspx
|
-
Насколько я помню, в классике модульного тестирования принято, что порядок выполнения модульных тестов не определен - то есть, модульные тесты не могут зависеть от результатов выполнения других модульных тестов. Но разработчики mstest пошли еще дальше: среда исполнения многопоточна и запускает на выполнение несколько модульных тестов одновременно. Это означает, что нужно быть очень осторожным, если в коде ваших тестов используются статические объекты, такие как "Одиночки" (Singleton) или фабрики классов, поведение которых зависит от внешних условий, задаваемых индивидуально в каждом тесте. Например, это может быть фабрика классов внутри тестируемой системы, которая создает реальный объект или "дублера для тестирования" (Test Double, он же в просторечии mock object ) в зависимости от заданного модульным тестом режима. Проще всего даже будет отказаться от подобных сценариев и решать задачу внедрения зависимостей другими способами, например через конструктор или специальное свойство. А родробнее про исследование порядка выполнения модульных тестов можно прочитать у Naysawn Naderi: That Pesky MSTest Execution Ordering..
|
-
По какому-то странному стечению обстоятельств разработчики Team Explorer упустили возможность изъятия для редактирования (check out) хранящихся на портале группового проекта документов непосредственно из узла Documents. В результате, открыть документ для редактирования можно, но при сохранении есть вероятность переписать текущую версию без сохранения истории изменений. Частично проблему в TFS 2008 и Windows SharePoint Services 3.0 можно решить таким образом. В SharePoint заходим в настройки контроля версий для нужной библиотеки документов (Settings | Document Library Settings | Versioning Settings) и для опции Require documents to be checked out before they can be edited? ставим Yes. Теперь, даже если документ был открыт для редактирования, переписать текущую версию без явного выполнения операции Check out не получится. С другой стороны, если вы используете Office 2007, то изъять документ для редактирования можно непосредственно из Word или Excel сразу же после открытия. Более удобное решение потребовало бы написания адд-ина к Team Explorer, что уже само по себе - задача нетривиальная, но еще сложнее, мне кажется, было бы получить URL документа, на котором нажали правой кнопкой мыши. Быстрый поиск в Google, возможно, именно по причине сложности реализации, такого решения не нашел.
|
-
В новой версии, из самого интересного, обещают: - Наконец-то, "родной" человеческий инструментарий для подписки на события
- Поддержка переименования пользователей в Windows/Active Directory
- Обновление Team System Web Access,которое выйдет сразу на 10 языках, но на месяц позже
|
-
Хотя я уже довольно много времени занимаюсь TFS, его хранилище данных и создание собственных отчетов до сих пор оставались terra incognita. В основном, из-за "технологического барьера" - в своем программистском прошлом сталкиваться с OLAP не приходилось вообще, а с отчетами - очень поверхностно. Но... все когда-то бывает в первый раз. Сейчас одна из моих задач на работе - разработка метрик для нашего процесса разработки, а известно, что без автоматического сбора данных метрики, по-хорошему, не работают. Благо, наши разработчики все активнее используют TFS, который собирает довольно много данных автоматически, а там, где этого не хватает, задача решается вводом одного-двух дополнительных полей. Собрать данные мало - их нужно обработать, чтобы получить интересующие показатели, а потом представить в удобоваримой форме. Чтобы не писать "голословно-теоретическую" спецификацию, я решил поэкспериментировать, сделав один-два отчета-прототипа, иллюстрирующих общую концепцию. Пришлось закатать рукава и разобраться в том, как устроено хранилище данных TFS, что такое схема "звезда", как создавать запросы к многомерному кубу и показывать результаты хотя бы в виде простенького отчета. Начать мне очень помогли брошюра Creating and Customizing TFS Reports и пост в блоге Team WIT Tools под названием Understanding the TFS Cube - без этих материалов мое разбирательство затянулось бы на несколько дней, а так уже через часов 6-7 чистого времени (и то, по большей части из-за разбирательства с аггрегирующими функциями в языке запросов MDX) был получен первый результат. Очень рекомендую всем, кто планирует работать с хранилищем данных TFS. По моим впечатлениям, самое трудное, если вы раньше не сталкивались с OLAP - понять, как "работают" хранилища данных и построенные по ним многомерные кубы. Освоившись с этим, уже гораздо легче будет понять структуру куба TFS Warehouse и "набить руку" в использовании его основных измерений (dimensions) и мер (measures) - заодно попрактикуетесь в составлении MDX-запросов. С получением же данных из самого хранилища, если вы раньше работали с базами данных Microsoft SQL Server, серьезных проблем вообще быть не должно - хотя сама схема базы и отличается от привычных нам 3й и более высоких нормальных форм, во всем остальном получение данных происходит точно также (за исключением не всегда очевидных пар первичных и внешних ключей). Пока что я не планирую заниматься отчетами серьезно, на уровне производственной эксплуатации, но чем, как говорится, черт не шутит... поэтому добавил себе в закладки подборку материалов.
|
-
В идеале, при гибкой (Agile) разработке процесс сборки решения и его развертывания в среде тестирования или опытной эксплуатации должен быть полностью автоматизированным, как и большая часть самого тестирования - это позволяет производить сборку и ее тестовый прогон как минимум раз в день. Такая частота тестирования помогает выявлять дефекты практически сразу же после того, как они были внесены в код, а общеизвестно, что стоимость исправления дефекта очень быстро растет со временем. К сожалению, в стандартной поставке Team Build отсутствует возможность сборки инсталляционных пакетов, но не беда: решения существуют как для стандартных проектов создания инсталляций, так и для нестандартных/сторонних решений: Обычные проекты создания инсталляций Visual Studio (.vdproj)
Web Deployment Projects
WIX 2.0
|
-
Сегодня искал информацию о структуре хранилища данных TFS (data warehouse) и попутно набрел на блог разработчика из Норвегии, который описывает свою эпопею создания своего адаптера к хранилищу для накопления статистики о метриках кода. Интересно, кто-нибудь вообще пытался создавать адаптер для других целей? - мы в свое время писали собственный тоже именно для сбора метрик. К сожалению, записи в дневнике обрываются перед Рождеством 2007 года, поэтому неизвестно, чем закончилось дело, удалось ли Tommy запустить адаптер. Я написал ему письмо, дай Бог, ответит... Между тем, если вы занимаетесь подобной задачей, стоит почитать его заметки, чтобы обойти наиболее вероятные "грабли": Октябрь 2007 г.
Ноябрь 2007 г.
Декабрь 2007 г.
|
-
Любопытно, но, похоже, пока еще никто не реализовал полноценную подписку на события TFS (eventing service) через RSS-каналы. Есть отдельные некоммерческие реализации для подсистемы контроля версий (и то, судя по коду, делает рекурсивный обход дерева, а не накапливает информацию от поступающих событий) и для отслеживания статуса групповых сборок. А вот какого-то универсального решения, которое позволяло бы мне "на лету" создавать нужные мне RSS-каналы, не существует. Как идея, при реализации можно было бы использовать механизмы TFS Migration and Synchronization Toolkit для периодического получения списков изменений в рабочих элементах и системе контроля версий - но еще вопрос, лучше ли это с точки зрения производительности, чем подписка на события и последующий анализ данных без дополнительной нагрузки на TFS... С другой стороны, при использовании событий их придется где-то накапливать для последующей обработки, и периодически вычищать это хранилище по критерию "срока давности".
|
-
Поиск рабочих элементов, содержащих заданный текст - задача, встречающаяся довольно часто. Однако же, в Team Explorer нет встроенной функции поиска, а городить "одноразовые" запросы - неудобно и непроизводительно. К счастью, существует более удобное решение: небольшой add-in для Visual Studio, который предназначен именно для этой цели:
http://blogs.msdn.com/noahc/archive/2007/03/08/search-work-items-team-system-addin.aspx
Add-in бесплатный, с открытым исходным кодом, написан сотрудником Microsoft. "Инструкция по эксплуатации" (кстати, ее советую-таки прочитать - в текущей версии настройка шаблона запроса для поиска неочевидна) - в упомянутом выше посте.
Upd: Коллега подсказал альтернативный add-in, которым пользуется сам и очень доволен:
http://www.acorns.com.au/projects/vsaddins/
|
-
Набрел случайно на презентацию о шаблоне процесса для TFS на основе принципов гибкой разработки (фактически - некий гибрид SCRUM и XP) от ThoughtWorks. Понравился шаблон рабочего элемента для Story - формализовано описание "Как [персона] я хочу [потребность] для того, чтобы [какой практический результат получу]" Hint: В этой компании работает Мартин Фаулер
|
|
|
|