Обзор работы с Mighty Moose

Обычный цикл разработки с помощью ТDD подразумевает использование подхода Red-Green-Refactor, который конечно же работает хорошо и при одного теста и знании горячих клавиш достаточно производителен. Однако, если затрагивается сложный функционал, то при рефакторинге кода могу затрагиваться самые разные тесты и тогда приходится вручную запускать все тесты, дабы убедится что ничто не сломано и все работает как планировалось. Вот это действие уже накладное и может вызывать большие потери времени разработчиков при запуске всех тестов и ожидании результатов, даже если предположить, что все тесты написаны качественно и проходят очень быстро.

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

В видео подкатом я в обзорном режиме показываю как работать с Mighty Moose.

 

Hard’n’Heavy!

 

 

Непрерывное тестирование с Mighty Moose

Уже очень давно не утихают разговоры про Test Driven Delepoment и большинство разработчиков скорее всего уже на собственном опыте ощутили насколько безопасным и приятным становится разработка и рефакторинг приложений, когда существуют тесты. Полный набор тестов.

Обычный цикл разработки с помощью ТDD подразумевает использование подхода Red-Green-Refactor, который конечно же работает хорошо и при одного теста и знании горячих клавиш достаточно производителен. Однако, если затрагивается сложный функционал, то при рефакторинге кода могу затрагиваться самые разные тесты и тогда приходится вручную запускать все тесты, дабы убедится что ничто не сломано и все работает как планировалось. Вот это действие уже накладное и может вызывать большие потери времени разработчиков при запуске всех тестов и ожидании результатов, даже если предположить, что все тесты написаны качественно и проходят очень быстро.

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

Подробнее

TFS Aggregator

Или как автоматизировать некоторые действия в TFS 2010.

Сразу скажу, что для TFS 2012 автор обещает быстро выпустить обновленную версию, однако, на мой взгляд, с учетом того, что API не поменялось или мало поменялось, то данный небольшой проект вполне может завестись и на новом TFS 2012 RC.

Идея

Последние статьи повествуют о настройке шаблонов процессов для TFS, но данные шаблоны оторваны друг о друга, по сути, хотя и связываются в работе связями типа: Child, Parent, Related To и так далее. Было бы логично использовать эту связь, для добавления интерактивности во всю схему, чтобы элементы действительно были связанны, чтобы они действительно реагировали на состояния друг друга в зависимости от типа связи и состояния. Чтобы можно было делать некоторые аккумулирующие подсчеты в метриках, ведь все эти данные доступны и их можно использовать в автоматическом режиме, сокращая время рутинных действий.

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

Например, представим себе ситуацию, когда пользовательская история имеет полный набор артефактов и готова к работе, созданы конкретные задания для реализации этой истории. В данной ситуации история находится в состоянии Ready For Development, а все задачи в состоянии Proposed. Разработчик берет задачу в работу, меняет ее состояние на Active. Далее он должен поменять состояние истории на WIP (Work In Progress). Однако этот шаг ведь можно автоматизировать! А автоматизация в свою очередь ведет к большему порядку и красоте. Т.е. как только разработчик взял задачу в работу, состояние всей истории поменялось автоматически!

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

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

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

Подробнее

Шаблон Agile в TFS2010 и TFS2012

После всех описаний существующего шаблона и модификаций для TFS2010, сподобился посмотреть, как это все выглядит в новом TFS, тем более что совсем недавно вышел Release Candidate и его можно поставить локально, чем я и занялся на досуге. Результатом был приятно удивлен.

Вместе с TFS2012 RC вышел и TFS Power Tools для него, что позволяет наглядно отобразить схему перехода состояний. Схема работы с TFS Power Tools не изменилась, так что сразу перейдем к рассмотрению различий.

Первое, что бросается в глаза, это более широкий набор рабочих элементов.

Некоторые элементы были переименованы, некоторые ушли, некоторые появились, рассмотрим, как элементы из TFS2010 соответствуют элементам из TFS2012:

Назначение TFS2010 TFS2012
Основной рабочий элемент, единица работы. Task Task
Запрос на новый функционал, бизнес-история. User Story Product Backlog Item
Баг Bug Bug
Затруднение в работе Issue Impediment
Тестовый сценарий Test Case Test Case
Общие шаги для тестовых сценариев Shared Steps Shared Steps

Подробнее

Настройка процессов в TFS – II

В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio.  Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.

На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.

Подробнее

Настройка процессов в TFS

Сложность 100

Речь пойдет о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS при выборе шаблона Agile для проекта.

Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.

Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды.  В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.

Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

Подробнее