Раньше мы использовали 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.
Поэтому, для облегчения разделения багов и тасков по версиям, я сгруппировал их в соответствующие каталоги.
Выглядит это вот так:
Тестировщикам еще нужны дополнительные запросы (например, 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)
И как TFS? Помимо того, что всё стало в одном месте? Разработчикам, тестировщикам - удобно?
ОтветитьУдалитьМне вот лично TeskTrack был очень симпатичен.
Сейчас используем бесплатный Redmine, но не торкает, совершенно. Хотя функций вроде бы даже и побольше, и то что есть в TestTrack'е - в редмайне тоже есть. Но при этом, юзабилити различается кардинально!
Плюс к тому, сам концепт браузерного багтрекера - это не интерактивно. Медленно.
Спасаюсь только сторонним нотифаером, ставящимся в трей - правда, он тоже кривоватый :)
Да, TestTrack весьма удобен.
ОтветитьУдалитьВ чем-то, я бы даже сказал, удобнее TFS.
TFS работает на запросах к work item'ам, что не очень удобно - т.е. постоянно приходится нажимать Refresh чтобы обновить списки, сам он этого не делает. Соответственно нет уведомлений о том, что тебе пришел новый баг и т.п.
Веб-интерфейс мне тоже не нравиться - медленно и неудобно. Если бы с TFS нельзя было работать через студию, мы бы точно не стали на него переходить.
Но в целом, я бы сказал, что TestTrack удобнее, чем TFS. Как-то в нем больше заботы о людях, на мой взгляд. Хотя может быть просто привычка сказывается......
Кстати, насколько я понял из даташита TestTrack Pro, оно тоже в студию интегрируется. Правда, это в новой версии, в 2010й.
ОтветитьУдалитьЖаль, цена у них будь здоров. Нам врядли купят :(
Ну, TestTrack Pro в студию всегда интегрировался, правда это была интеграция на уровне отображения панельки тест-трака в студии.
ОтветитьУдалитьНо, к сожалению, в нем не было связи багов с чекинами и кодом. Т.е. нельзя было по багу найти изменения в коде и смержить их с бранчем для подготовки патча. В TFS можно.
На сколько я знаю в связке JIRA+SVN это тоже делается, но только какими-то сторонними компонентами.
подожди! интеграция SVN + TestTrack у нас была, еще при мне. Там номер бага надо было ставить при коммите через VisualSVN.
ОтветитьУдалитьа дальше, вопрос только дисциплины. ругать тех, кто коммитит больше 1го бага за раз :)
если все качественно вносят номера багов, то потом изменения ищутся через TortoiseSVN без всяких проблем.
Ну это да, но тут понимаешь, интеграция глубже - т.е. при чекине тебе дает список твоих багов и предлагает отметить галочками те, которые связаны с изменением. При это баги тут же при чекине отмечаются как пофиксенные.
ОтветитьУдалитьА потом из багов можно посмотреть чекины и изменения. Т.е. все в одном месте.
А у кого нет студии - все это можно посмотреть через веб.
Рекомендую не тянуть с автоматизированными билдами - очень удобно. Правда у нас SVN и для билдов используется TeamCity.
ОтветитьУдалитьДа, сейчас движемся в этом направлении.
ОтветитьУдалитьОсновной вопрос - организовать автоматическую синхронизацию структуры баз - они у нас довольно сложные и меняются динамически в процессе функционирования системы.
Большая часть таким изменяющихся частей вынесено в отдельные базы, которые не будут автоматически синхронизироваться, но не все, что и является проблемой на данный момент.
изменения в таблицах всё-таки, мне кажется, лучше синхронизировать с помощью патчей.
ОтветитьУдалитьт.е. разработчики должны коммитить патчи вместе с соответствующим кодом. да, вам если эту проблему решить, то остальное должно быть просто, MSDeploy 4ever :)
Да, согласен, я думаю, что MSDeploy как раз то, что нам нужно.
ОтветитьУдалитьПо поводу патчей для БД - мне этот вариант не очень нравится по нескольким причинам:
1. Все-таки удобней пользоваться визуальным интерфейсом при работе с базой, чем DDL.
2. Патчи придется составлять вручную, при этом можно что-то забыть.
3. В патчах будет важно соблюсти порядок выполнения запросов, потому что выполняемые изменения могут зависеть от ранее выполненных изменений.
4. Иногда (правда сейчас уже довольно редко) бывает такая ситуация, что изменения в БД производятся вручную непосредственно на одной из рабочих систем (это в случае каких-то непредвиденных обстоятельств). Соответственно, при выходе новой версии эти изменения должны быть приведены в соответствие всем другим системам, что при ручном составлении патчей будет довольно сложно.
А смотрели в сторону SQL Server Project, о нём Леша Рага писал некоторое время назад? Правда про 2008-ую версию. У меня пока времени посмотреть что есть оно нет.
ОтветитьУдалитьНет, не смотрели.
ОтветитьУдалитьВообще, только начинаем подбираться к автоматизированной выгрузке.
Изменяющиеся части вынесли БД уже в отдельну базу.
Очень интересно как заставить программистов ассоциировать чекин с WI, я имею ввиду, можно ли сделать эту связку обязательной?
ОтветитьУдалитьДа, можно сделать так, чтобы при чекине надо было обязательно указать Work Item.
ОтветитьУдалитьДелается это в настройках Team Project Settings -> Source Control, затем выбираете Check-in Policy и добавляете Policy Type "Work Items". В его описании сказано "This policy requires that one or more work items be associated with every check-in."
Собственно, у меня именно так и настроено.
Однако, при чекине, разработчик может отказаться соблюдать данную полиси при данном чекине - но тогда в комментарии к чекину он будет должен указать причину, по которой он это хочет сделать.