TeamCity и другие

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

Прежде всего, мы вернули управление задачами в JIRA, отказавшись от тяжеловесного Rational Team Concert и TFS (хотя про TFS плохо говорить не хочу).

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

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

Кроме того, одновременно с юнит-тестами проводится статистический анализ кода при помощи утилиты FxCop 10, запуск которой мы также настроили в TeamCity. Отчет о найденных недочетах в коде можно увидеть непосредственно в TeamCity.

После удачной сборки и тестирования проекта производится его автоматическое развертывание в тестовое окружение - на тестовый сервер. Выполняется это также средствами TeamCity.

Для развертывания тестовой базы данных мы в TeamCity настроили запуск EMS DB Comparer, который сравнивает схемы девелоперской и тестовой баз, создает change script и выполняет его на тестовой базе. При этом он ведет историю сгенерированных скриптов, которую мы в будущем может анализировать или как-то использовать. К сожалению, в данном проекте мы не смогли использовать утилиту VSDBCMD для развертывания database-проектов, создаваемых в Visual Studio, так как данный проект использует базы данных MySQL.

В качестве средства обмена документами мы начали использовать Google Docs вместо опять же достаточно тяжелого SharePoint. Совместно используемую проектную область через Google Drive можно замапить себе на локальный диск, что очень удобно.

Для разработки тест-кейсов и формирования отчетов о тестировании мы начали использовать TestRail QA. Он нам представляется более удобным, чем TestLink, который мы использовали раньше.

Последнее, на чем хочу остановиться - это Source Control - он остался в TFS и это единственная функция, которая за ним остается на данный момент.


Таким образом, обобщая все, что я сказал выше, получаем следующий список инструментов:

• Source Control - TFS
• Управление проектом - JIRA (вместо TFS)
• Сборка проекта и выполнение юнит-тестов - TeamCity (вместо TFS)
• Статистический анализ кода - FxCop
• Синхронизация баз данных - EMS DB Comparer
• Обмен документами - Google Docs (вместо SharePoint)
• Тест-кейсы - TestRail QA

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

Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

С начала этого месяца мне уже три раза задавали вопрос "Как настроить номер итерации по умолчанию в TFS?".

Ответ на этот вопрос я упонимал здесь, но, поскольку часто спрашивают, решил ответить еще отдельным постом.

Ответ: Никак. Но есть обходной вариант.

Номер итерации хранится в поле Iteration Path, а TFS не позволяет для поля Iteration Path создавать правило DEFAULT, так что значение по умолчанию задавать нельзя. Кроме того, правило PROHIBITEDVALUES задавать также нельзя, поэтому нельзя запретить указывать старые итерации, которые уже остались в прошлом.

Для того, чтобы решить эту проблему я отказался от использования поля Iteration Path и вместо него создал свое аналогичное поле, но только не типа TreePath, а типа String со списком доступных значений, соответствующих списку нужных итераций.

Для этого поля уже было можно задавать значение по умолчанию и вообще любые правила.
Старое поле Iteration Path на форме Work Item'а я заменил на новое и исправил все запросы к списку work item'ов так, чтобы они использовали новое поле вместо старого.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Как поместить свой control на форму Work Item в TFS (Team Foundation Server)

Преамбула.
Вообще говоря, задача, ради которой я решил посмотреть как добавлять свои контролы была такова: довольно часто случается ситуация, когда в текст бага в TFS помещается Stack Trace исключения, которое происходит в работе системы.

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

Проще говоря, на форме ошибки решили поместить кнопку, при нажатии на которую в Visual Studio будет открываться строка кода, указанная в Stack Trace в Details текущего Work Item.

В этом посте я расскажу о том, как добавлять свои котролы на форму Work Item'а, в следующем - как настроить локацию кода.

Создание контрола для Work Item Type.

Прежде всего в студии создаем новый проект типа Class Library который назовем TFSControlsLibrary.

Затем добавляем в проект новый User Control, назовем его LocateCodeControl.

После создания, помещаем на него кнопку LocateCodeButton, с текстом “Locate code”.

После этого имеем новый контрол такого вида:




Подключаем в проект две библиотеки:
1. Microsoft.TeamFoundation.WorkItemTracking.Client (путь: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.WorkItemTracking.Client.dll)
2. Microsoft.TeamFoundation.WorkItemTracking.Controls (путь C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.WorkItemTracking.Controls.dll)

Созданный нами контрол LocateCodeControl наследуем от интерфейса IWorkItemControl.

Реализуем интерфейс что называется “по-умолчанию”:


После этого код контрола имеет следующий вид:

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Drawing;

using System.Data;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using Microsoft.TeamFoundation.WorkItemTracking.Controls;

using Microsoft.TeamFoundation.WorkItemTracking.Client;

namespace TFSControlsLibrary

{

public partial class LocateCodeControl : UserControl, IWorkItemControl

{

public LocateCodeControl()

{

InitializeComponent();

}

#region IWorkItemControl Members

public event EventHandler AfterUpdateDatasource;

public event EventHandler BeforeUpdateDatasource;

void IWorkItemControl.Clear() { }

void IWorkItemControl.FlushToDatasource() { }

void IWorkItemControl.InvalidateDatasource() { }

System.Collections.Specialized.StringDictionary IWorkItemControl.Properties {get; set;}

bool IWorkItemControl.ReadOnly {get; set;}

void IWorkItemControl.SetSite(IServiceProvider serviceProvider) { }

public object WorkItemDatasource {get; set;}

string IWorkItemControl.WorkItemFieldName {get; set;}

#endregion

}

}

Сам контрол на этом готов и если все сделано правильно, то проект должен компилироваться.


Теперь для подключения контрола к TFS в нашем проекте создаем xml-файл с раширением .wicc, который будет использоваться TFS для загрузки библиотеки обработчика контрола. Назовем его LocateCodeControl.wicc


Вот текст файла (как видим, он содержит имя сборки и имя класса контрола.):

<?xml version="1.0" encoding="utf-8" ?>

<CustomControl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<Assembly>TFSControlsLibrary</Assembly>

<FullClassName>TFSControlsLibrary.LocateCodeControl</FullClassName>

</CustomControl>

После всех манипуляций проект будет иметь следующий вид:





Теперь добавим немного поведения (в качестве теста) для нашей кнопки.

Создадим ей обработчик события Click по которому будем просто отображать Title текущего Work Item’а в MessageBox.

Код обработчика очень простой:

private void LocateCodeButton_Click(object sender, EventArgs e)

{

var ds = WorkItemDatasource as WorkItem;

MessageBox.Show(ds.Title);

}

Теперь приступим к тестовому развертыванию нашего контрола.


Для этого необходимо поместить откомпилированную библиотеку контрола и .wcc файл (в нашем случае это файлы TFSControlsLibrary.dll и LocateCodeControl.wicc) в каталог "C:\ProgramData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0" на каждой машине, на которой будет использоваться данный контрол, так как исполнение кода осуществляется локально, а не на сервере и если этого не сделать, то студия будет писать, что не находит контрол.


После этого можно поместить контрол на форму для какого-либо Work Item Type.

Встроенный в студию Process Editor делать этого не умеет, поэтому придется править xml-файл нашего Work Item'а вручную.

Для этого экспортируем Work Item Type из имеющегося Team Project в локальный xml-файл.

Затем находим этот файл и подключаем в него наш контрол в следующем виде:

<Control Type="LocateCodeControl" />

Затем импортируем наш файл обратно в Team Project.

После этого закрываем Visual Studio и снова открываем ее, иначе она не загрузит наш контрол. Для повторного развертывания наших файлов ее, кстати, также надо будет закрывать, так как она блокирует файлы.

Если все сделано правильно, то при создании бага видим нашу кнопку на форме:





При нажатии на кнопку видим наш MessageBox:





На этом первичное создание контрола завершено, в следующем посте я расскажу о том, как обеспечить локацию кода по Stack Trace в тексте бага.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Как создать work item в TFS (Team Foundation Server) из письма в Outlook

Некоторое время назад встала задача создавать баги в TFS из писем в Outlook без использования Visual Studio и Web Access.

Для решения задачи был создан add-in для Outlook.

Процесс создания описан ниже.

Прежде всего создаем проект Outlook 2007 Add-In.


После этого имеем текст класса нашего компонента в следующем виде:



Для начала создадим панель в Outlook, которая будет называться “TFS Integration toolbar”

Подключим несколько сборок:

using System.Windows.Forms;
using Microsoft.TeamFoundation.WorkItemTracking.Client;
using Microsoft.TeamFoundation.Common;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Server;



Затем модифицируем метод ThisAddIn_Startup следующим образом:




В начале метода мы создаем панель:



Затем помещаем на нее два контрола:
1. ComboBox MyAssignedToList, который будет содержать список сотрудников, для создания бага
2. Собственно кнопку CreateWIButton, которая будет приводить к созданию бага. Для кнопки определяем обработчик события Click.

Список значений для поля "Assigned To" будем отображать в MyAssignedToList. Для этого заполняем его доступным списком значений из нашего Team Project в TFS.

На этом подготовка к работе нашего контрола закончена.


Теперь реализуем обработчик события Click для нашей кнопки:



Здесь находим выделенное письмо, подключаемся к TFS и создаем наш баг.

На этом проект готов.

Теперь в Visual Studio делаем публикацию проекта, получаем инсталляционный пакет и запускаем его.

Компонент устанавливается, затем перезапускаем Outlook и включаем нашу панель:



После нажатия на кнопку “Create TFS Bug” создает work item типа Bug, который назначен на выбранного сотрудника и содержит в теле текст выбранного письма.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Учет трудозатрат, времени сотрудников и отчетность в TFS (Team Foundation Server)

В этом посте я продолжаю описание своего опыта внедрения TFS (Team Foundation Server), начатое здесь, здесь и здесь.


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

Деятельность наша продукто-ориентированная, а не проектно-ориентированная, поэтому не было необходимости учета и сравнения плановых и фактических трудозатрат - речь шла только о фактических трудозатратах.

На выходе необходимо было иметь отчет следующего вида:

Task name	Development hrs	Testing hrs	Management hrs
Task 1	...	...	...
Task 2	...	...	...
Task 3	...	...	...

Лирическое отсупление

Перед внедрением учета трудозатрат я опросил несколько коллег, работающих в различных небольших компаниях на предмет того, как у них организован учет трудозатрат. Ответы были следующие: - Учет трудозатрат не ведется. - Учет трудозатрат ведется суммарно по двум направлениям - разработка и исправление багов. Трудозатраты по отдельным задачам и трудозатраты на тестирование не учитываются. - Учет трудозатрат ведется по компонентам разрабатываемого продукта. Трудозатраты по отдельным задачам на учитываются. Практически никто из опрошенных: - не ведет учет плановых трудозатрат - не сравнивает фактические и плановые трудозатраты - не связывает баги с задачами (некоторые вообще для задач использует один инструмент, для ошибок - другой) - не суммирует время, потраченное на исправление ошибок, к задаче, к которой относятся данные ошибки (у многих вообще нет разницы между задачами и ошибками).

Для того, чтобы организовать учет времени по выполняемым задачам мне пришлось добавить в task два поля - DevelopmentHours и TestingHours.

Эти поля были предназначены для учета фактических трудозатрат на разработку и тестирование и при создании задач автоматически устанавливались равными нулю.

Требовалось сделать так, чтобы при переходе task'а из состояния Active в Completed разработчики должны были указать задать значение поля DevelopmentHours.
Аналогично при переходе из состояния Completed в Closed или обратно в Active тестировщики должны были указать значение TestingHours.

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

Для решения задачи пришлось использовать правило NOTSAMEAS, которое сравнивает значение поля со значением другого поля и если они совпадают, то не позволяет сохранять задачу. В качестве второго поля должно было бы выступать предыдущее значение DevelopmentHours или TestingHours в зависимости от ситуации. Поскольку в задаче сами по себе предыдущие значения не хранятся, пришлось добавить еще два поля, которые пользователю не видны и которые используются для хранения предыдущих значений - DevelopmentHours2 и TestingHours2.

Эти поля автоматически заполняются с использованием правила COPY значениями полей DevelopmentHours и TestingHours при сохранении задачи.

Таким образом, когда у разработчика возникает необходимость изменить статус задачи с Active на Completed у него значения полей DevelopmentHours и DevelopmentHours2 совпадают и он не может сохранить задачу, пока не изменит поле DevelopmentHours. При сохранении задачи новое значение DevelopmentHours копируется в DevelopmentHours2 и они снова становятся одинаковыми, чтобы в следующий раз вновь обеспечить необходмость изменения поля DevelopmentHours.

Выглядит это так:

Для TestingHours и TestingHours2  все работает абсолютно аналогично, но только при переходе из состояния Completed в Closed или обратно в Active.

Таким образом разработчики должны каждый раз указывать новое значение поля DevelopmentHours, а тестировщики - TestingHours.

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

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

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

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


Отчетность.

Для организации отчетность в TFS используется технология Reporting Services.
Открыть Диспетчер отчетов можно через портал проекта, а можно прямо из Visual Studio:

Для создания отчета пришлось использовать Visual Studio 2008 - в Visual Studio 2010 подходящего типа проекта почему-то не оказалось.

Для создания отчета необходимо создать проект типа Report Server Project, в котором создать .rdl-файл, являющийся описанием требуемого отчета.

В качестве источника данных была указана хранимая процедура, которая возвращала список work item'ов с типом task, так как только для них был организован учет трудозатрат.

При написании запроса к базе TFS было установлено следующее:
1. Все work item'ы хранятся в таблице WorkItemsAre. Тип при этом хранится в поле [Work item Type]. Т.е. если вы хотите выбрать все задачи, то можно написать такой запрос:

select *
from WorkItemsAre
where [Work item Type] = 'task'
 
2. Все поля (в том числе и добавляемые дополнительно) хранятся в таблице Fields. Дополнительно создаваемые поля имеют в данной таблице FldID начиная с 10 000.

При этом имя поля из таблицы WorkItemsAre составляется так - Fld + FldID поля из таблицы Fields.

Для примера, :
Поле DevelopmentHours в таблице Fields имеет FldID = 10133.
Соответственно его значение хранится в таблице WorkItemsAre в поле Fld10133.

Таким образом сначала определяем имя поля из таблицы Fields, а потом делаем составной запрос к таблице WorkItemsAre.

Т.е. примерно так:

declare @FieldName varchar (255), @q nvarchar (4000)

select @FieldName = 'Fld' + CONVERT (varchar (255), FldID)
from Fields
where ReferenceName = 'ROI.DevelopmentHours'

set @q = 'select ' + @FieldName + '
from WorkItemsAre
where [Work item Type] = ''task'''

exec sp_executesql @q
 
 
Таким образом можно определить и выбрать практически все интересующие поля.
Тип полей при этом совпадает с типом поля, заданном в TFS.

Используя хранимые процедуры можно написать практически любой запрос на получение данных из таблицы work item'ов, что и было сделано.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Нумерация версий продукта в TFS (Team Foundation Server)

В продолжении темы миграции в TFS (Team Foundation Server), начатой здесь и здесь, я произвел еще несколько изменений в процессе работы с ним, направленных на повышение удобства работы.

1. Я отказался от использования свойства Iteration Path, которое содержало номер текущей итерации проекта.

Дело в том, что наша деятельность не проектная, а продуктовая, поэтому для нас намного важнее номер текущей версии продукта, на которой мы работаем, чем номер итерации работы над ним. Кроме того, при переходе к работе над очередной версией мы не создаем новый Team Project - мы продолжаем работать в старом, просто новым задачам и багам присваиваем номера новой версии.

Свойство Iteration Path в принципе выполняло отлично свою функцию (тем более что оно было связано в деревом папок в Team Queries), если бы не одно обстоятельство - для него нельзя было устанавливать значения по умолчанию, запрещенные значения и т.п.
Это приводило к тому, что члены команды, которое мало работают с TFS, путались, забывали выставлять это значение, оставляли в качестве значения корневой элемент дерева и т.п. В будущем это стало бы создавать еще большую путаницу, так как с временем количество версий будет увеличиваться и сотрудникам пришлось бы постоянно работать с длинным списком версий, что неудобно.

Так что я убрал свойство Iteration Path с форм ввода ошибок и задач и заменил его на новое поле Version, которому уже задал список значений, соответствующих списку доступных номеров версий продукта. Для поля я Version задал значение по умолчанию, соответствующий текущему номеру версии, так что никто теперь по идее не будет путаться, какую версию выставить. А для задач и багов, запланированных на следующую версию можно всегда вручную установить следующее значение.

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

Хотя конечно если что-то будет неудобно, то будем менять.

2. Я уменьшил количество запросов в Team Queries.
Ранее я писал, что у меня были такие запросы, как My current tasks, My current bugs, All tasks, All bugs и т.д.

Сейчас я оставил в каждой версии продукта только по два запроса: My current work и Tasks and bugs.
- My current work отображает для каждого сотрудника список его активных задач и ошибок, относящихся к выбранной версии.
- Tasks and bugs содержит все задачи и ошибки данной версии.

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

Кроме того, безотносительно версий, я оставил следующие запросы:
- All my work - отображает всю историю задач и ошибок для данного сотрудника.
- All work items - отображает все work items.
- List fixes - отображает список багов и задач, выполненных за последние два дня. Очень удобно для отслеживания прогресса работы.
- My current work - отображает все активные задачи и баги, назначенные на данного сотрудника.

Таким образом, дерево запросов сейчас имеет следующий вид:

Название папок в дереве как и раньше соответствуют версиям продукта.

Продолжение темы - здесь.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Кто ошибку создает - тот ее и проверяет?

Вчера я произвел некоторые изменения в workflow ошибок в нашем Team Project. Как я уже упоминал ранее здесь шаблон проекта, был создан на основе Agile-шаблона, входящего в стандартную поставку TFS.

В workflow ошибок при закрытии ошибки она автоматически назначалась на ее создателя. Видимо это была реализация правила "Кто ошибку создает - тот ее и проверяет". Этот постулат я помню кто-то настоятельно популяризировал на ЛАФ-2010.

Еще тогда он у меня вызвал сомнения, а сейчас я в полной мере осознал его неудобство.

Т.е. если баг создала служба поддержки, или один разработчик создал баг для другого разработчика, или например ПМ создал баг - все они не должны заниматься проверкой багов, это просто не их работа. Баги должны проверять тестировщики.
И даже если тестировщик создал баг, то его последующее назначение на него же, тоже не вполне удобно. Тестировщик может например уйти в отпуск.
Кроме того, не понятно, что означает данное назначение - то, что тестировщик должен проверить баг или это баг, который он сам должен исправить (например, баг в его unit-тестах).
В общем путаница получалась.

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

P.S. Продолжение темы здесь и здесь.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)

Миграция в TFS (Team Foundation Server)

Итак, вчера я провел миграцию к TFS (Microsoft Team Foundation Server).
Раньше мы использовали SVN для контроля исходного кода, TestTrack Pro для управления багами и тасками, Groove для управления документами, календарями и т.п.

Теперь TFS используется для контроля исходного кода, он же используется для управления задачами и багами. Программисты и тестеры используют Visual Studio для работы с ним, все остальные работают через SharePoint-портал, который был создан для проекта. Особой разницы в функцинале портала и Team Explorer я не заметил.
Задачи и баги из TestTrack Pro в TFS переносить не стали - все таки база накоплена довольно большая - более 10-ти тысяч багов и тасков. Решили что они пока поживут одновременно. Т.е. фиксим баги в TestTrack Pro, новые пишем уже в TFS.

Перед миграцией в Process Editor я создал шаблон проекта (на основе Agile-шаблона) который мы использовали для создания проекта.

Для удобства сотрудников я создал в шаблоне готовый набор запросов, необходимый в повседневной работе - My current tasks, My current bugs, All tasks, All bugs и т.п. Кроме того, отдельные запросы созданы для каждой версии нашей системы. Поскольку каждая следующая версия системы не создает в TFS новый проект, все задачи и баги у нас будут храниться в одном Team Project.
Поэтому, для облегчения разделения багов и тасков по версиям, я сгруппировал их в соответствующие каталоги.
Выглядит это вот так:

Таким образом каждый сотрудник может использовать эти фильтры для работы с work items по версиям.
Тестировщикам еще нужны дополнительные запросы (например, Need to verify - список багов и тасков, нуждающихся в проверке), но они сделают их сами.
Еще из полезных запросов - Fixed today и Fixed in the last 2 days - я сделаю на днях.
Списки My current tasks, My current bugs вынесены на главную страницу SharePoint-портала.

Кроме запросов, в шаблоне проекта были внесены также изменения в набор полей для тасков и багов.
Были добавлены следующие поля:
1. Required architecture review - установка этого свойства означает, что разработчик должен согласовать способ устранения бага с архитектором.
2. Update text on site - установка этого свойства означает, что после завершения бага или таска, программист должен переназначить баг на тех. писателя, который внесет дополнения в подсказки на сайте.
3. Need to deploy - требуется ли выгрузка систему для проверки данного бага. Полезно для тестировщиков на случай, если какой-то баг решается без выгрузки и может быть проверен достаточно быстро.



Все документы из Groove были перенесены в Shared documents SharePoint-портала. Теперь все документы одновременно доступны в Groove, SharePoint или Visual Studio. Groove и SharePoint синхронизируются автоматически каждый час. Работа с файлами в Groove реализована значительно удобнее, чем в SharePoint, поэтому используем его.
К сожалению календари, встречи и т.п. у Groove и SharePoint интегрировать не удалось. Все это по прежнему остается в Groove. Баги тоже не удалось интегрировать в Groove.

С какими сложностями пришлось столкнуться в процессе миграции:
1. Как оказалось TFS может создавать бранчи только на основе каталогов файловой системы. Посколько у нас не все проекты Solution'а хранились в одном каталоге, при миграции от этого пришлось отказаться - т.е. пришлось переместить все проекты в один каталог. Несколько нелогично со стороны Microsoft - давать такую возможность в Visual Studio, но не предусмотреть ее в TFS.

2. Как оказалось, TFS не может складывать последние версии бранчей в один и тот же каталог - вместо этого он складывает их в разные каталоги. Это приводит в тому, что нельзя так же просто, как и раньше, когда мы работали с SVN, использовать IIS для отладки сайтов - в IIS для приложений пути прописаны в явном виде. Видимо, для того, чтобы использовать уже сконфигурированное приложение, после взятия последней версии нового бранча, нам придется вручную исправлять пути приложений в IIS. Это несколько неудобно. Странно, что в Microsoft не предусмотрели решения такой, в общем-то довольно очевидной проблемы.

3. Как оказалось в студии по умолчанию нет поиска багов или тасков по номеру или подстроке - только запросы. Очень неудобно, особенно тестировщикам. К счастью для решения проблемы уже есть plug-in - http://visualstudiogallery.msdn.microsoft.com/en-us/3f31bfff-5ecb-4e05-8356-04815851b8e7


Из положительных результатов миграции хотелось бы отметить следующие:
1. Отсутствие зоопарка инструментов. Раньше был TestTrack, Groove, SVN. Теперь осталась только студия и немного Groove.

2. Возможность явной связи изменений в коде с багом или таском. Раньше такого не было и для выгрузки патча программистам приходилось писать в комментариях к багу список измененных файлов. Теперь стало очень удобно - при чекине в TFS можно легко ассоциировать чекин с багом или таском и потом по истории обновления бага или таска посмотреть историю изменений кода. Очень удобно.

3. Удобная возможность мержа кода от основной ветки разработки к стабильным бранчам для подготовки патчей (что было очень неудобно в SVN).

4. Высокий потенциал на будущее - возможность автоматизированных сборок на сервере, запуска unit-тестов, деплоймента и пр.


Из недостатков:
1. Как оказалось в TFS нельзя назначить баг или таск сразу нескольким сотрудникам. В общем-то это небольшая проблема и требуется довольно редко. Можно сказать, что можно вполне обойтись и без этого.

2. В TFS нет как такового общего списка багов или тасков - вместо этого есть только запросы. В принципе ничего страшного, но потенциально существует опасность потерять какой-нибудь work item, составим неверный запрос.

3. При назначении человеку бага или таска у него не выскакивает сообщение, как это было в TestTrack Pro. Иногда полезно.

4. Списки багов и тасков не обновляются автоматически - приходится жать Refresh.

5. Нет возможности изменить историю работы с work item. Т.е. если в комментарии забыли что-то написать и хотим добавить - надо взять весь комментарий, скопировать его, вставить и уже потом исправлять.

А в остальном все не плохо.

Теперь в планах - наладить автоматизированный запуск unit-тестов (сейчас тестировщики запускают их вручную) и автоматический деплоймент на тестовые сервера.
Но это уже осенью.


P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)