Дмитрий Лапшин

Поддержка недокументированных атрибутов в описании формы рабочего элемента

2009-03-16T13:14:03Z

До октября 2008 года при работе с Process Template Editor существовало значительное неудобство – если в описании формы рабочего элемента имелись недокументированные атрибуты, например, MinimumSize, то при попытке редактировать форму выдавались сообщения об ошибке, а при сохранении описания рабочего элемента “непереваренные” атрибуты попросту выбрасывались.

В октябрьском релизе, похоже, добавили полноценную поддержку недокументированных атрибутов, что (при желании) полностью избавляет от необходимости ручной правки XML-файлов и работы с утилитами командной строки witimport/witexport.

Если TFS Power Tools отказываются сохранять WITD на диск

2009-02-25T13:17:59Z

У меня иногда бывает так, что TFS Power Tools после очередного редактирования вдруг отказывается сохранить описание типа элемента декомпозиции работ (во какой новый перевод я придумал для "work item" ). При этом выдается ошибка (вернее, это предупреждение, но сохранить измененный файл Visual Studio при этом не дает):

Сannot find a schema that defines target namespace 'http://schemas.microsoft.com/dsltools/WITDesigner', schema validation skipped

Как оказалось, избавиться от этой ошибки можно только одним способом, а именно - удалив файлы с расширениями .wit и .wit.diagram, оставив только сам .xml файл с описанием типа элемента декомпозиции работ. Power Tools сами пересоздадут эти файлы при следующем открытии .xml файла, при этом, правда, вы потеряете текущее расположение графических обозначений состояний и переходов на вкладке Workflow.

Пока что у меня нет точного понимания причин возникновения этой ошибки, предполагаю, что к ней приводит ручное обновление (или экспорт с сервера) .xml файла, при этом файлы .witd и .witd.diagram рассинхронизируются с самим описанием типа, и это "сбивает с толку" Power Tools.

Поддержи украинское .NET сообщество - проголосуй за интересующую тебя тему!

2009-02-12T08:55:00Z

Предпринимаются срочные меры, чтобы вывести украинское сообщество .NET разработчиков из летаргического сна, о котором писал в своем блоге Саша Кондуфоров. Надо признать, в последнее время темы для семинаров выбирались из двух вариантов - либо приезжает кто-то из Microsoft с готовой темой, либо у кого-то из экспертов есть тема, по которой ему/ей было бы интересно выступить. И в том, и в том случае не факт, что тема вызовет интерес у большинства профессиональных разработчиков - и посещаемость той же UNETA в последнее время - тому свидетельство.

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

Поэтому - большая просьба ко всем голосовать за предложенные варианты или предлагать свои здесь:
http://dev.net.ua/forums/7732/ShowThread.aspx#7732

О глобальных списках и связи рабочих элементов со сборками

2009-01-28T07:07:24Z

Уверен, многие знакомы с полями рабочих элементов "Found In" и "Integrated In", с помощью которых можно связать, например, дефект с той сборкой программного продукта, в которой он был найден, или сценарий использования с той сборкой, в которой он был реализован. Это ускоряет и разработку, и тестирование, так как Quality Assurance больше не надо тратить время на выяснение того, какую именно сборку нужно проверять, а разработчикам - на попытки воспроизведения дефектов, которые тестировщик нашел в сборке 10-дневной давности, и которые давным-давно исправлены

Особенность полей Found In и Integrated In - автоматическое заполнение списка доступных значений номерами всех когда-либо производившихся в рамках данного группового проекта сборок. Эта "уличная магия" работает на самом деле очень просто - для каждого группового проекта при завершении первой же сборки в Team Foundation Build создается глобальный список с названием "Builds - <Имя группового проекта>". В дальнейшем список пополняется при завершении каждой последующей сборки. В описаниях самих же полей правило SUGGESTEDVALUES просто ссылается на вышеупомянутый список.

Есть, правда, один нюанс. Если вы копируете описание типа рабочего элемента (Work Item Type Definition) из одного группового проекта в другой (или импортируете тип рабочего элемента из файла), обязательно проверьте набор правил для полей Found In и Integrated In. Скорее всего, вам нужно будет исправить или вовсе удалить (если в групповом проекте еще не производилось ни одной сборки) ссылку на глобальный список - в противном случае, Team Explorer будет вам "подсказывать" неправильные номера сборок.

Политики регистрации изменений и права доступа к контролю версий

2008-12-26T22:14:55Z

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

С разграничением доступа к рабочим элементам уже все налажено, а вот с правами на доступ к контролю версий обнаружились интересные (и, судя по всему, нигде не задокументированные) "грабли". Мне понадобилось ограничить доступ определенной группе сотрудников только одной папкой. Так вот, оказалось, что выдачи всех необходимых прав на папку недостаточно, чтобы регистрировать в ней изменения. Team Explorer попросту отказывается это делать, мотивируя невозможностью получить с сервера политики регистрации изменений. Поиск по коду и сообщению об ошибке ничего не дал, поэтому я чисто интуитивно попробовал дать группе права на чтение корневой папки группового проекта. Удивительно, но - сработало! Берите, в случае чего, на вооружение!

Быстрое включение/выключение анализа покрытия кода тестами

2008-12-25T21:29:56Z

Определение процентажа покрытия кода тестами - дело полезное, но далеко не всегда нужное при сборке решения на рабочей станции разработчика. Кроме того, для определения процентажа покрытия в сборки вносятся специальные изменения, а это тоже далеко не всегда желательно. Напрашивается необходимость в быстром включении/выключении этой функциональности, поскольку ставить/снимать галочки в окне "Select artifacts to instrument" - не выход, особенно когда решение сложное и содержит большое число проектов.

Я для себя решил задачу созданием двух тестовых конфигураций, одной с выключенным анализом покрытия, другой - соответственно, с включенным. Создать вторую конфигурацию очень просто. Выбираем Test | Edit Test Run Configurations, затем в появившемся диалоговом окне свойств конфигурации жмем Save As... и сохраняем ее под другим именем. Затем, переключение между конфигурациями можно быстро осуществить с помощью меню Test | Select Active Test Run Configuration.

Подарок от Санта-Клауса: Новый образ виртуальной машины с VSTS 2008 SP1 Trial

2008-12-25T21:00:15Z

До самого Рождества Microsoft не раскрывали планов по поводу публикации обновленных образов виртуальных машин с пробными версиями TFS 2008 и VSTS 2008. Единственным предлагаемым в форумах вариантом было скачивание специальной программы, которая одноразово продлевала срок годности старой виртуальной машины на месяц. Но, как известно, чудеса случаются именно на Рождество - и именно под Рождество стали доступны обновленные образы виртуальных машин со сроком годности до конца 2009 года:

Visual Studio® Team System 2008 Team Foundation Server SP1 VPC Image (Trial)
Microsoft® Visual Studio® Team System 2008 Team Foundation Server SP1 and Team Suite SP1 VPC Image (Trial)

Рабочие элементы: состояния и переходы между ними

2008-11-12T21:47:51Z

Уже неоднократно наблюдал ситуацию, когда люди, переходящие на TFS с других программ управления требованиями или дефектами, испытывают трудности с непривычной для них, основанной на двух, а не одном, полях системой статусов - или, как они называются в TFS, состояний. Порой даже "родная" система полностью игнорируется, а вместо нее заводится привычное поле "Status" с привычной же кучей всевозможных значений

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

С другой стороны, в родной системе состояний нет совершенно ничего "военного" - к ней попросту нужно привыкнуть. В основе лежит несколько простых и логичных принципов:

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

Proposed - рабочий элемент предложен для рассмотрения, но еще не принят в работу - например, клиент предложил новую функциональную возможность, но команда не будет ее реализовывать в текущей итерации.
Active - над рабочим элементом ведется работа - например, пишется код.
Resolved - рабочий элемент готов к проверке или тестированию - например, разработчик написал код и юнит-тесты, и все юнит-тесты проходят успешно.
Closed - никакие действия над рабочим элементом более не требуются, например, тестирование прошло успешно и функциональность вошла в очередной релиз.

Минимум состояний компенсируется множеством переходов из одного состояния в другое. Каждый переход представляет собой конкретную причину, по которой рабочий элемент оказался в том или ином состоянии. Например, в состоянии Active находятся как принятые в работу в текущей итерации рабочие элементы, так и те, которые "завалили" проверку или тестирование.

Небольшое количество состояний позволяет легко отслеживать динамику "движения" работы в команде. Например, большое количество рабочих элементов в состоянии Proposed может говорить о том, что либо у заказчика бурная фантазия и он придумывает функциональные возможности быстрее, чем команда в состоянии их реализовывать, либо существует узкое место в процессе утверждения в работу (например, перегружен менеджер проекта или заказчик не отвечает на письма и звонки). А большая очередь из рабочих элементов в состоянии Resolved может означать, что команде не хватает инженеров по тестированию.

Разумеется, цифра "четыре" - отнюдь не догма. Бывают случаи, когда большее количество состояний оправдано - например, чтобы отдельно отслеживать требования, которые были успешно проверены на тестовом окружении, но еще не попали в производственную эксплуатацию. С другой стороны, не стоит заводить состояния вида "Verified Fixed" или "Verification Failed" - такие значения, скорее, подходят для поля Reason.

Измерение качества кода с помощью Visual Studio 2008

2008-10-24T09:43:44Z

VS 2008 предоствляет 4 метрики, которые подробно описаны в блоге Code Analysis Team:
http://blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx

Взаимозависимость классов: чем она больше, тем больше вероятность регрессионных дефектов, сложнее писать юнит-тесты и делать рефакторинг;
Глубина наследования: сложные иерархии классов трудны для понимания, осложняют изучение кода новым членам команды. Обратите внимание, что реализация интерфейсов в этой метрике не учитывается.
Цикломатическая сложность: опять же, чем она больше, тем сложнее отлаживать и поддерживать код, сложнее тестировать, как следствие - повышается вероятность дефектов;
Количество строк кода: куда же без них На уровне классов позволяет выявлять "раздутые" ("три экрана кода") методы, которые логично разбить на несколько более мелких. Цикломатическая сложность, кстати, при этом может быть небольшой, если много действий выполняются строго последовательно.
Индекс простоты обслуживания: синтетическая метрика, учитывающая, в частности, количество строк кода, цикломатическую сложность и объем Халстеда.

Запросы, подписки и переименование областей и итераций

2008-10-17T20:20:50Z

В TFS можно переименовывать уже существующие области и итерации. Но при этом нужно учитывать, что если в ваших запросах присутствуют условия наподобие "Area Path under ...", где в пути фигурирует название переименованной области или итерации, то такие запросы перестанут работать. Для того, чтобы восстановить работоспособность запросов, откройте их для редактирования и исправьте условия, включающие поля Area Path или Iteration Path.

Та же самая ситуация с подписками на события. После переименования области или итерации нужно перепроверить условия и, при необходимости, обновить их.

Связи решают все

2008-10-15T21:24:08Z

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

VSTE for Developers и VSTE for Database Professionals - краще разом!

2008-10-03T20:13:02Z

Существование отдельной редакции 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.

Остается добавить только одно: МО-ЛОД-ЦЫ!

Об одной особенности прав доступа уровня области или итерации

2008-09-20T13:51:40Z

В 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

Осторожно: порядок выполнения модульных (unit) тестов

2008-08-14T14:51:23Z

Насколько я помню, в классике модульного тестирования принято, что порядок выполнения модульных тестов не определен - то есть, модульные тесты не могут зависеть от результатов выполнения других модульных тестов. Но разработчики mstest пошли еще дальше: среда исполнения многопоточна и запускает на выполнение несколько модульных тестов одновременно.

Это означает, что нужно быть очень осторожным, если в коде ваших тестов используются статические объекты, такие как "Одиночки" (Singleton) или фабрики классов, поведение которых зависит от внешних условий, задаваемых индивидуально в каждом тесте. Например, это может быть фабрика классов внутри тестируемой системы, которая создает реальный объект или "дублера для тестирования" (Test Double, он же в просторечии mock object ) в зависимости от заданного модульным тестом режима. Проще всего даже будет отказаться от подобных сценариев и решать задачу внедрения зависимостей другими способами, например через конструктор или специальное свойство.

А родробнее про исследование порядка выполнения модульных тестов можно прочитать у Naysawn Naderi: That Pesky MSTest Execution Ordering..

Check out и редактирование документов на портале проекта из Team Explorer

2008-07-16T10:31:42Z

По какому-то странному стечению обстоятельств разработчики 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, возможно, именно по причине сложности реализации, такого решения не нашел.