Список всего того, что починено:

• VS 2010 SP1 Changes (includes Test and Lab Manager)
• TFS 2010 SP1 Changes

Также, выпущен TFS Project Server Integration Feature Pack. В отличие от беты, он доступен на всех языках, на которых выпускается Visual Studio, в том числе и на русском. Читайте детали в документации.

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

Обновление work item type definition, в общем, не содержит больших подводных камней. Если вы их использовали как есть, то просто можно загрузить новые описания. Несколько запусков WITIMPORT и дело сделано. С Sharepoint дело ещё проще – хотите новые dashboards? Просто включите их.

А вот с отчётами немного сложнее. Как правило, их никто под себя не меняет (слишком нетривиальная задача), т.е. можно было бы просто положить новые и всё. Но, к сожалению, SQL Server Reporting не предоставляет удобного интерфейса для массовой загрузки отчётов, и, тем более, для изменения их параметров. А это необходимо для корректной их работы.

В общем, конечно, можно посмотреть файлик ReportsTasks.xml, который находится внутри Process Template, и является инструкцией для мастера создания нового проекта о том, как правильно размещать отчёты. Затем повторить “подвиг разведчика” руками, выкладывая каждый отчёт и настраивая его. Задача вполне осуществимая для отдельно взятого проекта. А если их много? Что делать?

На помощь, как всегда, приходят Team Foundation Server Power Tools. Команда ‘tfpt addprojectreports’ полезна не только для добавления отчётов в проект, который создали без них, но и для обновления проектов, в которох уже есть отчёты. Не забудьте ключик ‘/force’, который позволит обновить отчёты при наличии ранее созднанных. Таким образом Вы можете опубликовать отчёты, соответсвующие выбраннму Вами Process Template (задаётся опцией ‘/processtemplate’). Полезный совет – не пытайтесь запомнить полное название шаблона, под которым он зарегистирован на сервере. Просто укажите неправильный шаблон, и вам на экран выдадут весь список, откуда вы просто скопируете правильное название.

И ещё один нюанс. Если Вы обновляетесь с Agile/CMMI 4.x на 5.x, то обязательно возникнет коллизия с именами. Дело в том, что в версии 4.x в корне распологается отчёт ‘Builds’, а в версии 5.0 предполагается папка с таким же названием. TFPT сам с задачей превращения отчёта в папку точно не справится, так что ему придётся помочь – предварительно удалить или переименовать отчёт ‘Builds’.

Кстати, отчёты версии Agile/CMMI 5.0 весьма мощный и полезный инструмент.

Хоть это и происходит редко, последствия крайне неприятны, особенно в том случае, если Вы используете непрерывную сборку. Представьте – разработчик собирает в IDE проект, и со спокойной душой кладёт изменения в систему контроля версий. Далее происходит сборка продукта и она ломается. Разработчик в недоумении. Все поледующие изменения, внесённые другими членами команды тоже приводят к сломанной сборке и проблема растёт как снежный ком (ну, конечно, если у Вас нет TFS 2010 и gated chek-in).

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

В любом случае, чтобы убедиться в том, что проблема исправлена, необходимо собрать проект на машине разработчика так же, как его собирает Team Build.

В принцепе, это можно сделать из командной строки, натравив MSBuild на файл сборки TFSBuild.proj. На первый взгляд, задача выглядит не сложной. Но это только в том случае, если структура папок в системе контроля версий у Вас выбрана по-умолчанию. Если же, например, в одном проекте Вы храните разные ветки продукта, делаете ветвления (что очевидно для грамотной разработки проекта), то файл TFSBuild.proj, с большой долей вероятности, лежит в другом месте. В моём случае, есть следующая структура проектов:

Проблема заключается в том, что умолчательные пути для результата сборки и тестов будут располагаться по вот такому пути “..\..\Binaries” и “..\..\TestResults” соответсвенно. Это ещё половина беды, так как самое страшное в этом случае то, что результат сборки будет просто выше по иерархии. Это не красиво, но не смертельно. Хуже другое – запуск коммандной строки

MSBuild TFSBuild.proj

в папке Build, где у меня лежит файл проекта сборки, просто сломается. Дело в том, что MSBuild будет искать solution файл в папке “..\..\Sources”. В моём случае не обойтись без параметров:

MSBuild TFSBuild.proj –p:SolutionRoot=..\

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

<PropertyGroup>

  <!-- Set default paths for desktop build -->

  <BuildDefinition Condition=" '$(IsDesktopBuild)' != 'false' and '$(BuildDefinition)' == '' ">DesktopBuild</BuildDefinition>

  <SolutionRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(SolutionRoot)' == '' ">$(MSBuildProjectDirectory)\..\</SolutionRoot>

  <DesktopBuildOutputRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(DesktopBuildOutputRoot)' == '' ">$(MSBuildProjectDirectory)\..\TfsDesktopBuild</DesktopBuildOutputRoot>

  <BinariesRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(BinariesRoot)' == '' ">$(DesktopBuildOutputRoot)\Binaries</BinariesRoot>

  <TestResultsRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(TestResultsRoot)' == '' ">$(DesktopBuildOutputRoot)\TestResults</TestResultsRoot>

</PropertyGroup>

Обращаю внимание, что сделать это надо до строки импорта TFS build проекта:

<!-- Do not edit this --><Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /><ProjectExtensions>

В своей реализации я оставил возможность для эстетов таки переопредилить и мои умолчания

Теперь Вам будет легче убедить своих разработчиков отлаживать любые проблемы локально на своей машине, а не “тренироваться на кошечках”.

участие в конфернции AgileDays’09. Интересные люди и доклады. Вот, что мне особенно понравилось:

• Agile at Intel
• О бедном Аgile замолвите слово
• TDD + DDD + MVP + GoF + PoEAA= Love!

Забавно было поучаствовать в битве “MS Team System vs IBM Rational Jazz: лучший инструмент разработчика”.

Огромное спасибо Асхату Уразбаеву за организацию конференции!