Архив рубрики: TFS

Поддержка C# 6.0 на Build Server

Столкнулся с проблемкой, что при создании Build Definition для нового проекта билд падает со странной ошибкой вида:
ExtensionExceptionExtension.cs (22, 0)
Unexpected character '$'
Как выяснилось, на TFS сервере нет студии 2015 и не умеет он билдить C# 6.0.
Под катом как полечить.

1. На машину где установлен билд агент ставим Microsoft Build Tools 2015.
2. На машину где установлен билд агент ставим Microsoft .NET Framework 4.5.2 Developer Pack.
3. Перезагружаем машину где стоит билд агент.
4. В настройках Build Definition указываем атрибут для MSBuild: /tv:14.0

Все работает.


Настройка значений по умолчанию для автоматической выгрузки рабочих элементов из TFS в Project Server


При интеграции TFS и Project Server потребовалось, чтобы все созданные в TFS рабочие элементы сразу помечались для выгрузки в Project Server. Нормального описания даже на английском не нашел. Есть вот такое древнее в английской ветке MSDN, но во-первых в качестве правильного ответа помечен неправильный ответ, а во-вторых там надо править в XML. Под катом как это сделать через интерфейс в Visual Studio 2015.

Предварительная подготовка

Для работы с шаблонами рабочих элементов из Visual Studio необходимо установить TFS Power Tools. Раньше я про него не писал, поэтому здесь буквально пару слов, чтобы потом ссылаться на эту статью при необходимости.
В главном меню Visual Studio открываем Tools->Extension and Updates. В окне выбираем в левом дереве Online, в строку поиска вводим TFS Power Tools и нажимаем Enter:
Нажимаем Download и закрываем студию. По окончании закачки, запускаем инсталятор и устанавливаем расширение в режиме: далее, далее, далее.
Заходим в студию. В ней появились дополнительные возможности в пункте меню Team -> Team Project Collection Settings:

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

Все переходим к непосредственной настройке.

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

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

Напомню, что нас интересует два поля:
  • Отправить в Project Server (имя свойства Microsoft.Sync.ProjSrv.Submit)
  • Корпоративный проект (имя свойства Microsoft.Sync.ProjSrv.ProjectName)

Выбираем пункт меню Open WIT from Server (показан на предыдущей картике). В открывшемся окне выбираем рабочий элемент который необходимо настроить:
Открывается WIT задачи, в котором переходим на вкладку Workflow и открываем контекстное меню на Transaction создающей новый элемент:

Выбираем Open Details и в открывшемся окне переходим на вкладку Fields:

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

На второй создаем новое правило, и здесь самое интересное. Тип этого правило не Default, а Copy:
Выбираем что присвоение на основе значения и указываем Да (у меня на тестовом стенде русский шаблон, для английского указываем Yes):
Закрываем окна до вот этого в котором нажимаем New и настраиваем второе свойство (Microsoft.Sync.ProjSrv.ProjectName) по аналогичной схеме, в качестве значения указываем имя проекта в Project Server:
У меня проект в Project Server называется AgileProject, пожтому все выглядит вот так:

Закрываем все открытые окна по Ok. Сохраняем WIT кнопкой сохранить из панели инструментов Visual Studio.
После этого можем переходить в Web интерфейс TFS и пробовать создать новый рабочий элемент типа, который мы модифицировали. Если в браузере уже была открыта вкладка TFS, то необходимо обновить ее. Теперь при создании новой задачи у меня два свойства имеют нужные мне значения:

Ветки (Branch) и слияния (Merge) в TFS


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

Механизм создания веток позволяет некоторую папку в хранилище кода скопировать в другую папку хранилища как есть. Т.е. на момент создания ветки (branch) мы получим две папки абсолютно идентичные друг-другу и отличающиеся только названием. Для создания ветки, достаточно на любой папке открыть контекстное меню  и выбрать:
Ветки всегда создаются на сервере, т.е. после выбора этого пункта и ввода имени папки в которую необходимо делать ветку, на сервере TFS будет произведено копирование всех файлов с папки источника в папку приемник. Кстати, TFS запоминает все такие ветки и даже может их визуализировать. Первая картинка к этой статье, как раз показывает ветки одного из наших проектов. Правда визуализация немного хромает, если преобразовать ветку в папку. Но об этом в другой раз.
Зачем могут быть нужны две папки с абсолютно одинаковым содержимым? На самом деле, все просто. Вы можете сколько угодно изголяться над одной из веток и потом просто ее удалить. Во второй ветке у вас останется исходный код. Согласитесь неплохой способ проводить эксперименты. Еще одна замечательная возможность предоставляемая TFS заключается в слиянии (merge) веток. Если две папки связаны между собой в результате Branche, то выбрав одну из них, мы все изменения можем слить в другую (на картинке выше пункт merge):
В открывшемся окне мы можем выбрать в какую из веток выполнить слияние и указать, перенести все различия между ветками или можем выбрать конкретные наборы изменений которые необходимо перенести. Хранилище само определяет в чем заключается разница файлов хранящихся в ветках и вносит на машине пользователя необходимые изменения в локальные файлы. Т.к. в отличии от Brunch проходящего на сервере, Merge происходит на локальной машине и его нужно возвращать на сервер в рамках набора изменений. Это связано с тем, что при внесении изменений параллельно в двух ветках, при их слиянии могут возникнуть сложности с автоматическим объединением изменений в разных ветках одного и того же файла. И эти изменения придется выверять и подтверждать вручную.
Теперь о том, как мы эти ветки используем у себя.
Во-первых, у нас есть папка с набором базовых компонентов (Core). Эта папка размножается ветками в корневые папки всех крупных проектов. Делается это для того, чтобы при необходимости внести изменения (бывает очень редко, но бывает) в базовые компоненты, можно было эти изменения обкатать на том проекте которому они нужны. Слить эти изменения в исходную ветку, убедиться что в ней все хорошо и потом из коревой ветки слить изменения с веткой Core в остальных проектах. Т.к. во всех проектах настроены автоматические билды, то если в результате слияния изменений из Core в ветки проектов что-то пойдет не так, все разработчики узнают об этом сразу. Схематически это все выглядит вот так (картинки кликабельны):
Если еще не запутал, то во-вторых, ветки у нас применяются для разделения проекта. Разработка нового функционала ведется в основной папке проекта. Ближе к концу спринта, когда основной функционал реализован, все изменения перемещаются в заранее подготовленную ветку Prerelease. В этой ветке идет стабилизация версии перед релизом. После того, как QA дает отмашку на релиз, все изменения перемещаются в ветку Release и разворачиваются в эксплуатацию. Благодаря этим трем веткам всегда есть возможность спокойно проводить стабилизацию перед релизом, не опасаясь, того, что кто-то начнет писать новый функционал и сломает тот код, который в рамках стабилизации уже был подвергнут регрессу. Также, наличие ветки с кодом идентичным развернутому в Operation позволяет править ошибки обнаруженные в процессе эксплуатации именно в том коде, который эксплуатируется. И даже если в ветке разработки поправили модель данных или сломали вообще все, есть возможность внести минимальные изменения в стабильный код и развернуть его после проверки в эксплуатацию. Выглядит это примерно так:
Ну и объединяя две предыдущие картинки, схема веток Core и проектов будет выглядеть так:
На сегодня думаю хватит, а в следующий раз я тогда покажу как ветки связаны с тегами рабочих элементов и что приходится делать для некоторых из них.

О тегах в TFS


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

Сразу скажу, что тегов мы используем всего 7. Помечаются тегами только баги и PBI. Причем некоторые теги привязываются только к PBI, а некоторые только к Bug. Поехали.

NotReady
Этим тегом помечаются только PBI и только в основном бэклоге. Этот тег сообщает о недостаточной подготовке PBI. Как правило, это пометка о необходимости обсудить его с заказчиком.

added
Это тег тоже только для PBI, но уже в спринте. Им помечаются требования добавленные в спринт заказчиком после его начала, как правило с аргументацией: "А!!! Мы все умрем!!! Срочно!!!". Сразу оговорюсь, что ситуация хоть и плановая, но не массовая. По статистике за последние 40 спринтов, на 13-14 запланированных в начале спринта Effort приходится 1 Effort добавленный в итерации.

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

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

release
Этим тегом помечаются в основном баги, и он говорит об обнаружении ошибки в эксплуатации. У этого бага максимальный приоритет, он правиться в специальной ветке и после исправления и тестирования, исправление разворачивается на боевые сервера. Очень редко это тег ставиться на PBI, но это как правило небольшие изменения и в этом случае он идет еще и с тегом added.

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

prerelease
Применяется только к багам и говорит о том, что исправлять его нужно в ветке стабилизации перед релизом. Появляется только в конце спринта, когда вся разработка нового функционала завершена и идет именно стабилизация.

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