Ласкаво просимо до dev.net.ua Увійти | Приєднатися | Допомога | Увійти Live ID
в Пошук

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

  • Удаленное принудительное обновление TFS Data Warehouse

    Способ принудительного обновления TFS Data Warehouse с помощью ручного вызова метода Run Веб-службы WarehouseController из Internet Explorer хорошо известен, но обладает одним существенным недостатком - чтобы им воспользоваться, нужно иметь права интерактивного входа в систему на сервере, на котором установлен TFS application tier. А на серверах, использующихся в производственной эксплуатации, такие права дают очень ограниченному кругу людей. Чтобы обойти это ограничение, в свое время сотрудник Microsoft Eric Lee написал простенькую программку, делающую то же самое, но программно. К сожалению, Эрик, по всей видимости, полностью потерял интерес к своему детищу - в его оригинальном посте на сегодняшний день недействительны ссылки как на скриншоты, так и на собственно закачку программы.

    К счастью, мир не без добрых людей - дело Эрика подхватил некто Julien, который даже немного расширил возможности программы, добавив поддержку аутентификации путем ввода логина и пароля вручную (версия Эрика поддерживала только аутентификацию под именем пользователя, от которого запущена программа). Качаем, пользуемся, и говорим "Merci beaucoup" месье Жюльену:

    http://julien.lavigneducadet.com/index.php?2006/08/02/5-tfs-warehouse-update-with-authentification

  • Слайды с моего выступления на UNETA о юнит-тестировании

    Доступны на Microsoft Office Live по ссылке.

  • FxCop 1.36: Нашлась пропажа

    Как-то недавно понадобился мне FxCop 1.36… И вот - неприятный сюрприз: оказалось, что страничка для его скачивания на Microsoft Downloads  более не существует. Более того, поиск ни в Google, ни в “родном” Bing никаких работающих ссылок на скачку не дал – находилось лишь множество блог-постов, ссылающихся на ту самую более не существующую страницу.

    Начав (каюсь – незаслуженно) подозревать Microsoft в коварстве, а именно в ограничении доступа к возможностям статического анализа кода лишь для владельцев “старших” версий Visual Studio, я задал вопрос на форуме самого проекта FxCop на MSDN. Мне ответили, и, к счастью, все оказалось гораздо проще: теперь FxCop входит в Windows 7.1 SDK.

    Еще раз спасибо пользователю Grauenwolf.

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

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

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

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

    У меня иногда бывает так, что TFS Power Tools после очередного редактирования вдруг отказывается сохранить описание типа элемента декомпозиции работ (во какой новый перевод я придумал для "work item" Smile). При этом выдается ошибка (вернее, это предупреждение, но сохранить измененный файл 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 сообщество - проголосуй за интересующую тебя тему!

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

    До самого Рождества 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)

    Надіслане Thursday, December 25, 2008 11:00 PM від DmytroL | 1 коментарів
    Помічено як: ,
  • Рабочие элементы: состояния и переходы между ними

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

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

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

    1. Весь жизненный цикл рабочего элемента представлен в виде ориентированного графа. Состояния являются его вершинами, а переходы между ними - ребрами:
    2. Количество состояний рабочего элементов должно быть минимальным. В стандартных шаблонах их максимум четыре:
      • Proposed - рабочий элемент предложен для рассмотрения, но еще не принят в работу - например, клиент предложил новую функциональную возможность, но команда не будет ее реализовывать в текущей итерации.
      • Active - над рабочим элементом ведется работа - например, пишется код.
      • Resolved - рабочий элемент готов к проверке или тестированию - например, разработчик написал код и юнит-тесты, и все юнит-тесты проходят успешно.
      • Closed - никакие действия над рабочим элементом более не требуются, например, тестирование прошло успешно и функциональность вошла в очередной релиз.
    3. Минимум состояний компенсируется множеством переходов из одного состояния в другое. Каждый переход представляет собой конкретную причину, по которой рабочий элемент оказался в том или ином состоянии. Например, в состоянии Active находятся как принятые в работу в текущей итерации рабочие элементы, так и те, которые "завалили" проверку или тестирование.

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

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

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

    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 ссылки делятся на три класса:

    1. Внешние ссылки. Обеспечивают связь рабочих элементов с другими артефактами, такими, как наборы изменений или результаты тестов.
    2. RelatedLink: Ссылки на связанные рабочие элементы. С помощью этого класса ссылок можно обеспечить прослеживаемость, например, какие сценарии тестирования покрывают то или иное требование. Фактически, это подкласс внешних ссылок, выделенный для удобства в отдельную категорию как наиболее часто используемый.
    3. Гиперссылки. Здесь все очевидно - обойдемся без комментариев.

    Благодаря расширяемой архитектуре 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 - краще разом!

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

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

    Надіслане Friday, October 3, 2008 11:13 PM від DmytroL | 0 коментарів
    Помічено як: ,
Більше повідомлень Наступна сторінка »

Синдикація

Новини