Что такое visual studio team foundation server
Аннотация: В этой лекции: поддержка цикла разработки программного обеспечения в Microsoft Visual Studio Team Foundation Server ; использование Team Foundation Server в типичной группе разработчиков; использование Team Foundation Server в типичной группе тестировщиков; описание физической среды группы разработчиков и тестировщиков.
Обзор
В этой лекции рассказывается, как использовать Team Foundation Server (TFS) и Microsoft Visual Studio Team System (VSTS) в среде командной разработки ПО . Здесь рассматриваются основные возможности TFS и VSTS , а также автоматизация документооборота между группами разработчиков и специалистов по тестированию. В TFS объединены контроль качества исходного кода, наблюдение за ходом выполнения работы, составление отчетов, управление проектом и автоматизация процесса сборки. Это позволяет команде разработчиков работать более эффективно.
Успешный проект командной разработки ПО состоит из множества процессов, слаженная работа которых необходима для создания эффективной рабочей среды. К основным процессам относятся:
- разработка;
- тестирование;
- сборка;
- развертывание;
- выпуск.
В этой лекции вы познакомитесь с типичными приемами, которыми пользуются команды разработчиков и специалистов по тестированию при работе с TFS . Здесь описано, как использовать TFS для управления рабочим процессом и обеспечения продуктивного сотрудничества между группами.
Более подробную информацию об архитектуре и основных компонентах TFS вы найдете в лекции 2.
Логическая организация работы в Team Foundation Server
Продукт TFS позволяет команде разработчиков хранить исходный код в централизованном хранилище . Извлекая код из хранилища, при помощи сервера сборки вы создаете сборки (build) , а затем передаете их группе испытателей.
На рис.1.1 показано, как в TFS организован рабочий процесс и как связаны между собой среда разработчиков и среда испытателей.
Тестовая группа запускает результаты сборки в тестовой среде, проводя сочетание ручных и автоматических тестов. Результаты тестов хранятся в TFS и используются для организации обратной связи по вопросам качества сборки. Кроме того, тестовая группа может создавать рабочие элементы и ошибки (особый тип рабочего элемента), на которые группе разработчиков следует обратить внимание. Эти элементы позволяют группе тестирования отслеживать работу группы разработчиков.
Логическая организация работы в средах разработки, тестирования и производства
В крупных организациях, где имеется несколько групп разработчиков, у каждой из них есть собственный TFS с отдельными хранилищами и серверами сборки. На рис.1.2 показан пример логического потока операций для двух групп разработчиков, передающих сборки в объединенную группу испытаний.
увеличить изображение
Рис. 1.2. Логическая организация работ в двух группах разработчиков и одной группе комплексного тестирования
Каждая группа разработки по расписанию передает сборки в точку сбора, например, в общий сетевой ресурс . Группа тестирования извлекает сборки оттуда и проводит их испытания, определяя качество сборок. Когда контроль качества пройден, приложение развертывается на модельном сервере для итогового тестирования и проверки пользователями. После этого приложение развертывается на рабочем сервере.
Процесс разработки
Работая над проектом ПО, разработчики вовлечены в несколько ключевых взаимодействий с TFS . Например, разработчик взаимодействует с TFS следующими способами:
- Осуществляет доступ к ошибкам и задачам TFS , чтобы выяснить, какую работу ему нужно сделать. Рабочие элементы могут назначаться разработчику менеджером проекта, другим разработчиком или испытательной группой.
- Использует обозреватель исходного кода (Source Control Explorer) VSTS для получения доступа к хранилищу исходных кодов TFS и загружает последнюю версию исходного кода в локальную рабочую область или на свой компьютер.
- Выполнив назначенную задачу снова помещает код в БД управления исходным кодом.
Размещение кода может запустить процесс непрерывной сборки при помощи Team Build . Если сборка завершилась неудачей, создается новый рабочий элемент для отслеживания ошибки.
Процесс тестирования
Тестировщик взаимодействует с TFS следующими способами:
- Извлекает результат плановой сборки из точки сбора.
- При помощи различных инструментов VSTS выполняет ручное и автоматическое тестирование , включая проверку безопасности, производительности и работы в веб.
- Выгружает результаты испытаний в БД тестирования для последующего использования.
- Регистрирует ошибки, выявленные в ходе тестирования, как новые рабочие элементы TFS .
- Разрешает существующие ошибки, если они устранены в последней сборке.
Физические среды разработки и тестирования
Количество компьютеров в средах разработки и тестирования зависит от размера групп и объема проектов. На рис.1.3 изображена типичная физическая среда разработки и тестирования.
Среда разработки
Среда разработки служит для поддержки процессов разработки и сборки и содержит следующие компьютеры:
- сервер Team Foundation Server ;
- сервер сборок;
- сервер для сбора результатов работы сервера сборок;
- рабочие станции разработчиков.
Если группа разработчиков осуществляет удаленный доступ к TFS или размер ее столь велик, что отрицательно сказывается на производительности центрального сервера TFS , для повышения эффективности работы вы можете также настроить TFS -прокси.
Среда тестирования
Среда тестирования состоит из одной или нескольких рабочих станций, на которых установлен продукт Visual Studio Team Edition for Software Testers . Он используется для управления циклом тестирования, а также для выполнения функционального тестирования , системного тестирования , тестирования производительности и веб-тестирования. Члены группы используют TFS для управления рабочими элементами, ошибками и результатами тестов.
В среду тестирования также может включаться продукт Visual Studio Team Test Load для проверки производительности.
Резюме
Продукты VSTS и TFS предназначены для поддержки цикла разработки ПО и объединяют различные его аспекты, например, контроль качества исходного кода, наблюдение за ходом выполнения работы, составление отчетов, управление проектом и автоматизацию сборки.
TFS играет определяющую роль в обеспечении сотрудничества между группами тестировщиков и разработчиков. Группа разработчиков взаимодействует с TFS на протяжении цикла разработки, осуществляет доступ к системе контроля за исходным кодом, а также к ошибкам и рабочим элементам, чтобы выяснить, какие от нее требуются действия. Группа тестирования взаимодействует с TFS для запуска тестов, выгрузки результатов тестов и регистрации ошибок.
Какая первая ассоциация возникает, когда слышишь словосочетание Microsoft TFS? Что-то большое, неповоротливое и корпоративное. Именно так и было до появления Visual Studio Team Services и выхода MS TFS 2015. Первый — это облачная версия Team Foundation Server, которая опережает в развитии частную (private) версию примерно на три месяца. Одним из главным нововведений обновленного TFS/VSTS стала новая система сборок. Эта система позволяет достаточно просто писать свои шаги сборок, которые могут делать что угодно — от собственно сборки проекта до автоматического заведения дефектов и рассылки нотификаций. Кроме этого новая версия предоставляет развитый REST API для манипулирования задачами, дефектами и практически любыми сущностями в базе данных TFS.
Именно поэтому когда перед нами встал выбор новой системы управления жизненным циклом разработки, мы остановились именно на этой новой версии MS TFS. Мы используем TFS для полного цикла — планирование-разработка-тестирование-развертывание, и, поначалу все шло достаточно гладко. С ростом сложности задач, которые мы ставили перед системой сборки, появлялись и проблемы. К счастью, REST API и собственные шаги сборки позволили их с успехом решить. Далее я расскажу о проблемах и о том, как мы их решили.
Как не выйти в окно, когда нужно больше тестов
Нам нужна была сборка, которая запускает автотесты. Просто? Но идея была в том, чтобы объединить в нее несколько тестовых запусков по разным системам и отображать единый отчет о прохождении теста. Решение — сделать сборку с несколькими тестовыми запусками. Все было хорошо, пока мы не начали вылезать за пределы временного окна — тестовые запуски выполнялись последовательно один за другим. И не существовало решения "из коробки" для распараллеливания сборок. И пришла простая идея — мастер-сборка:
- запускает отдельные сборки на других агентах (параллельно)
- ожидает их завершения
- забирает себе их тестовые результаты, если есть
Из реализации этой идеи и родилось расширение Parallel Builds
Для обеспечения параллелльности в расширении содержится 2 шага сборки:
- Starter — запускает перечисленные определения сборок. Каждая сборка запускается со своими настройками. Это позволяет полностью изолировать разные сборки, использовать разные агенты и разные переменные окружения.
- Awaiter — ожидает выполнения запущенных сборок и собирает их тестовые результаты. Кроме этого он добавляет на страницу Summary текущей сборки ссылки на "оригинальные" сборки. Это нужно в первую очередь для того, чтобы можно было просмотреть консольный вывод и логи этих сборок в случае возникновения проблем.
В простейшем случае мастер-сборка состоит всего из двух шагов:
расширение работает и в облачном VSTS и в частном TFS. Написано на typescript поэтому требует агента версии 2.0.
Пусть дефекты создает робот — он железный
Автоматизация тестирования, она не в количестве автотестов, а в головах. Поэтому после третьего подряд разбора провалившихся тестов в тестовых запусках было решено переложить этот "интеллектуальный" труд на робота. Еще одно расширение? Именно так. Идея была в следующем:
Так в составе расширения Parallel Builds появился шаг — AutoDefects.
Автоматическое создание дефектов позволяет обеспечить обязательность реакции на провал теста, отследить жизненный цикл и собирать статистику о типе провала — дефект автотеста, развертывания среды или функциональный дефект тестируемой системы.
Jenkins не делится результатами — исправим
Разработка у нас ведется в кросс-функциональных командах и процесс разработки допускает использование командами своих инструментов разработки. С одним условием — они должны быть интегрированы с TFS. Некоторые команды по разным причинам используют для сборки Jenkins. Текущая версия интеграции TFS и Jenkins позволяет запустить сборку на Jenkins и дождаться ее выполнения. Но, к сожалению, не импортирует результаты выполнения тестов в этой сборке.
К счастью, с недавнего времени Microsoft поддерживает движение свободного ПО и публикует некоторые свои разработки на GitHub. Сборочные задачи для TFS в их числе
И вот pull request, который добавляет к JenkinsQueueJob функциональность импорта результатов из Jenkins. Кроме этого он позволяет добавить ссылки (относительные задачи в Jenkins) на Build Summary page в TFS. Например, можно добавить ссылку на артефакты этой сборки, которые хранятся на Jenkins сервере или дополнительные отчеты, например, Yandex.Allure
Новая версия TFS/VSTS позволяет настроить себя под совершенно разнообразные задачи и уже не похоже на того монстра, каким представлялся TFS раньше. А учитывая, что для небольших команд использование VSTS бесплатно, то он может быть инструментом не только для корпораций, но и для "стартапов".
Данная статья будет полезна тем, кто не устанавливал и не использовал Visual Studio Team Foundation Server раньше. TFS может быть частью очень сложной инфраструктуры, которая включает отчеты, интеграцию с SharePoint, множественные домены, распределенные базы данных и т.д., но я не собираюсь затрагивать эти области. Моя основная задача – это помочь разобраться с базовыми элементами TFS (система контроля версий, система отслеживания ошибок и заданий и система автоматических сборок) и начать использовать данную систему.
Предисловие
Для начала давайте рассмотрим, почему именно Team Foundation Server? TFS создана с целью интегрировать средства разработки для более быстрой и комфортной работы. Вы можете сами интегрировать разные системы вместе:
В этом случае каждая система имеет собственно хранилище данных, собственный набор идентификационных данных, собственные команды и инструменты. Конечно, это возможно, но при работе с такой системой будет уходить много времени на переключение между компонентами и поддержку.
TFS представляет собой систему, которая интегрирует все необходимые компоненты вместе.
В зависимости от необходимости, вы можете использовать только часть компонентов.
Существует множество способов для получения доступа к функционалу TFS. Если вы программист, то вероятно вы будете себя комфортно чувствовать, используя Visual Studio. Если вы тестировщик, вы можете использовать новый Team Explorer в качестве клиента, без необходимости устанавливать Visual Studio. Если вы руководитель проекта, то вы можете получить доступ к информации через web браузер или Excel, Microsoft Project или даже MOSS.
Установка TFS 2010
Забегая вперед, скажу, что этот процесс стал, как ни когда простым. Поэтому я решил не публиковать подробную инструкцию по установке (если же с установкой возникнут проблемы, рекомендую прочитать статью Установка Visual Studio Team Foundation Server 2010), а ограничиться лишь теоретическими знаниями.
Рассмотрим основные преимущества, которые предлагает новая версия TFS.
- TFS 2010 может быть установлен на контроллере домена. Разработчики TFS поняли, что многие небольшие организации не имеют возможность использовать выделенные серверы. Теперь если у вас есть только один сервер, который является контроллером домена, сервером электронной почты и т.п., появилась возможность установить на этот сервер и TFS 2010.
- TFS 2010 может быть установлен на персональные операционные системы – TFS 2010 устанавливается на Vista и Windows 7 Home Premium и выше. Ну и конечно, поддерживаются серверные операционные системы (Windows 2003, Windows 2008 и Windows 2008 R2). Теперь у вас появилась возможность запустить сервер управления версиями прямо на вашем рабочем ноутбуке.
- TFS 2010 может работать и на 32 и на 64 битной операционной системе!
После установки TFS в «Basic» режиме вы получаете: систему управлениями версиями, систему отслеживания ошибок и систему автоматизации сборок (непрерывное интегрирование – проще простого!). Для полного комплекта не хватает компонентов: SharePoint и системы отчетов. Данные элементы присутствуют в режиме “Standard”. Еще одна хорошая новость в том, что вы уже установили TFS 2010 “Basic” и теперь вы можете просто добавить компоненты по мере необходимости, без полной переустановки системы.
Система контроля версий в TFS 2010
И так после того, как вы получили достаточный багаж теоретических знаний и установили TFS 2010 самое время приступить к работе. В данной главе я рассмотрю основы по использованию системы контроля версий, которые предоставляет TFS 2010.
Предполагается, что у вас на компьютере уже установлен TFS 2010 и имеется Visual Studio 2010.
И так, первое что нам необходимо сделать, это подключить Visual Studio к TFS. Для этого воспользуйтесь главным меню (Team) или ссылкой на домашней странице:
Система попросит указать адрес существующего TFS. В моем случае мой Windows 7 ноутбук называется dionnis-pc.
После этого, окно Team Explorer должно содержать название соединения с сервером и DefaultCollection. Но на текущий момент у нас нет не одного добавленного проекта.
В поем случае, для примера я использую код Enterprise Library, но на самом деле, можно было ограничиться стандартным приложением (File, New Project, Windows Forms). Если вы сейчас попробуете добавить проект в репозиторий системы контроля версий, то Visual Studio выдаст ошибку:
Ошибка означает, что вам необходимо создать проект в TFS, который будет все компоненты необходимые для вашей работы. И так, нам сначала необходимо создать новый проект:
В следующем диалоговом окне необходимо указать название проекта и краткое его описание:
Теперь Visual Studio просит указать методологию, которую мы будем использовать при разработке нашего приложения. По умолчанию – Agile (гибкая методология разработки), но так же можно выбрать и CMMI. Для дополнительной информации по методологиям я рекомендую почитать MSDN. Я рекомендую остановиться на Agile, если вы не знаете что именно для вас подходит или если вы используете одну из гибкий методологий разработки (например TDD).
И так, наконец, Team Explorer отображает элементы текущего проекта: Work Items, Builds и Source Control.
Теперь вы можете добавить ваш проект в репозиторий.
Сейчас необходимо указать папку, в которой будет храниться наши данные.
При успешном завершения работы, Solution Explorer пометит файлы, которые претендуют на помещение в репозиторий символом “+”. Так же вы увидите список действий, которые необходимо выполнить для того, что бы поместить ваше приложение в репозиторий. Просто добавьте комментарий и нажмите Check-In:
Процесс добавления файлов в репозиторий необходимо подтвердить:
И так, поздравляю! Вы добавили свой проект в репозиторий!
Cистема отслеживания ошибок в TFS 2010
После того, как мы разобрались, как работать с системой контроля версий, самое время рассмотреть принцип работы системы отслеживания ошибок.
Записи об ошибках и заданиях в Visual Studio относятся к рабочим элементам (work items). Создать один из видов рабочих элементов можно непосредственно из панели Team Explorer в Visual Studio. Это же можно сделать, используя web интерфейс или инструменты Visual Studio Test и Lab Management. В нашем случае я использую панель Team Explorer:
Поскольку мы только начали работу над проектом, то в списке не должно быть никаких записей.
Теперь если обновить список ошибок, то можно увидеть только что созданную запись.
Если все прошло гладко, то файл будет содержать отметку, о доступности для редактирования.
После редактирования, панель Pending Changes в Visual Studio сама покажет список файлов, которые претерпели изменения.
Поскольку мы исправляли ошибку, необходимо сделать запись об этом:
После того как отметили исправленную ошибку и добавили комментарий, можно смело копировать файлы в репозиторий:
Теперь можно убедиться, что статус ошибки изменен, и получить дополнительную информацию о подробностях исправления.
Еще один способ работать с TFS
Получить доступ к рабочим элементам проекта, можно используя web интерфейс. Для этого необходимо просто использовать адрес вашего сервера:
Данный метод может оказаться наиболее эффективным для людей, которые не привыкли работать с Visual Studio. Так же есть возможность использовать Excel и Microsoft Project.
Сборки в TFS 2010
Для полного (минимального) комплекта не хватает только научиться работать со сборками. С этим пробелом и призвана бороться данная глава статьи.
Для начало необходимо определить параметры сборки. Для этого воспользуемся уже знакомой панелью Team Explorer в Visual Studio.
Тут я хочу немного рассмотреть возможные параметры.
Особый интерес представляет вкладка Trigger. На этой вкладке вы можете задать события, на основе которых будут собираться сборки:
- Manual – сборка задается вручную, по требованию.
- Continuous Integration – сборка происходит сразу после check-in’а (после копирования файлов в репозиторий). Данный метод очень эффективен, если вы хотите делать сборки не дожидаясь объединения изменений.
- Rolling builds – метод, при котором все изменения будут собираться пока выполняется предыдущая сборка. Данный метод рекомендуется использовать, если у вас очень большой проект и сборка занимает много времени (больше, чем скорость с которой вносятся изменения).
- Gated Check-in – данный метод позволяет быть уверенным, что все изменения корректно компилируются, до того как файлы попадут в основной репозиторий.
- Scheduled – метод, при котором вы задаете расписание, по которому происходят сборки. Например, во многих компаниях хорошей практикой является создание ежедневных сборок.
При таком богатом наборе вариантов, вы можете создавать всевозможные виды сборок исходя из ваших потребностей.
Следующей важной вкладкой при настройке сборки является вкладка — Build Defaults. Здесь необходимо указать папку, в которую будет помещен результат после сборки.
Теперь вы можете сохранить параметры сборки и убедиться, что она стала доступна в панели Team Explorer. Давайте добавим новую сборку в очередь на выполнение.
Если вы дважды кликните по сборке в очередь, то увидите подробную информацию о выполнении.
Через некоторое время появится и результат.
В моем случае результат оказался не утешительным, но это сейчас не имеет значения. Надеюсь, что у вас будет все в порядке! Данный отчет предоставляет подробную информацию обо всех ошибках и предупреждениях, которые были найдены, так что из этого отчета сразу можно перейти к коду, который вызвал ошибку.
И так, мы рассмотрели инструменты, которые предлагает TFS для создания сборок. Теперь вы полностью готовы обеспечить минимальный жизненный цикл вашему продукту, используя TFS.
На этом я заканчиваю статью посвященную TFS и желаю вам побольше интересных проектов!
И самое главное – не забывайте получать удовольствие от программирования!
Многие программисты по мере своего развития выбирают для себя стезю управления разработкой, с сожалением ограничивая себя в творческом процессе изучения новых языков программирования и технологий.
И, начиная с этого момента, мы уже как руководители вынуждены бороться со сложностью разработки программных проектов, сложностью их однородного понимания всеми участниками и сложностью учёта изменений, происходящих постоянно при изменениях внешней среды. Ориентируясь на пророческое утверждение Брукса о том, что серебряной пули нет, мы всё же ищем способ найти управленческую технику, увеличивающую, хотя бы и не на порядок, производительность, надёжность и простоту в разработке программного обеспечения.
Итак, каждый из руководителей знает, что такое диаграмма Ганта, и каждый пользовался MS Project. Ещё больше читателей, программистов, использует систему управления задачами. И практически все программисты-не одиночки используют систему управления исходным кодом.
Перед нами стоит вполне прагматическая задача обеспечить единый процесс разработки, когда при учёте каждого нового изменения требований можно наглядно увидеть изменение параметров проекта.
Сформулируем эту задачу на прикладном уровне. Представим проект как набор этапов, которые в свою очередь состоят из перечня высокоуровневых задач, каждая из которых включает ряд пользовательских сценариев, стори, а те – декомпозируются в таски. Мы нарочно и дальше будем использовать в статье такую смешанную терминологию, не то ГОСТ, не то Agile, так как заказчики смотрят на проект примерно на уровне детализации этапов, и им вообще не интересно знать, что такое Agile, а разработчики смотрят на задачи примерно на уровне тасков и им в свою очередь не интересно думать о ГОСТах.
Далее, мы должны добиться того, чтобы при поступлении новых данных о проекте репланнинг с учётом всей доступной информации проходил максимально быстро, и мы могли получить максимально быструю обратную связь по проекту в целом, чтобы предоставить её Заказчику (или учесть в собственных маркетинговых ожиданиях при разработке собственного продукта).
Какими инструментальными средствами должны теперь мы воспользоваться для того, чтобы достигнуть цели? Представлю следующие критерии выбора этих инструментальных средств:
1) Необходима диаграмма Ганта как визуальное средство и как инструмент для планирования этапов
2) Инструментальные средства должны позволять проводить декомпозицию высокоуровневых задач в пользовательские сценарии, а их – в таски для программистов и аналитиков
3) Инструментальные средства должны автоматизированным способом обеспечивать взаимосвязь при изменениях между задачами в высокоуровневой диаграмме Ганта и тасками. Например, если мы ошиблись с оценкой одного из тасков, и у программиста на задачу ушло времени в два раза больше, то это может привести и к увеличению продолжительности одного из высокоуровневых этапов. А поскольку мы не хотим, чтобы сроки высокоуровневого этапа были сорваны, то мы должны провести анализ критического пути, чтобы заново сбалансировать требования и ресурсы. Наши инструментальные средства, благодаря взаимосвязям между уровнями, должны помочь нам увидеть проблему с возможными срывами сроков на диаграмме Ганта
4) Желательна также возможность отслеживания связей между тасками программистов и исходным кодом в системе управления исходным кодом
5) Система управления исходным кодом в свою очередь должна поддерживать модель бранчинга, например, подойдёт связка git+gitflow
6) В системе управления задачами необходима возможность отмечать фактически назначенное время и учитывать величину остатка по времени, а также получать отчёты о ходе выполнения работ
Существует несколько вариантов выбора подобных инструментальных средств, рассмотрим три из них, которые кажутся нам наиболее подходящими:
1) MS Project + Team Foundation Server
2) Jira
3) Redmine
Jira и Redmine рассмотрим в следующих статьях, а в этой сосредоточимся на MS Project + Team Foundation Server (+ Visual Studio).
Использование MS Project и Team Foundation Server
Предположим, что мы работаем на Государственное Ведомство, и после совещания мы получили задачу через неделю выкатить сайт, который под нагрузкой сможет держать «всех граждан нашей страны, которые туда зайдут» и мобильное приложение.
Работа есть работа, в Project создаём следующий план:
В этом плане мы видим задачки на разработчиков, аналитиков, дизайнера, верстальщика, тестера и инженера. Задачи сбалансированы по порядку следования, не пересекаются для отдельных исполнителей, содержат в одном из случаев разрыв для эффективного распределения нагрузки.
Все специалисты полны энергии и рвутся в бой, поэтому нужно получить из этого плана список задач в TFS. В TFS предварительно должна быть создана Коллекция, в ней создан Проект (а его надо создавать в Visual Studio, я выбрал в качестве шаблона процесса MSF for Agile Software Development 2013.4).
Для настройки выгрузки в TFS, переходим в Project на вкладку Team, которая появляется после установки TFS, и выбираем командный проект:
Дальше публикуем задачи:
… и сталкиваемся с проблемой:
Ну, канешна, как же я сразу не догадался: надо ведь определить типы элементов для TFS! Чтобы это сделать, необходимо добавить столбец Work Item Type в Project, который появился там после установки TFS. Обратите внимание на то, что для правильной группировки элементов в TFS тип объемлющих задач должен быть User Story, а у содержащихся в них задач – Task.
На скриншоте видно, что я добавил не только Work Item Type, но ещё и Area Path, и Iteration Path. Эти поля также необходимы, чтобы создать задачи в TFS, они характеризуют, соответственно, модуль в разрабатываемой системе и версию.
Нужно привязать указанные ячейки по смыслу, отследив, чтобы и соответствующие ресурсы были в AD, и Area Path, и Iteration Path были созданы:
… и попробуем опубликовать данные ещё раз. Для просмотра задач необходимо также воспользоваться Visual Studio, там всё стандартно, подключаемся к Коллекции, Проекту и выполняем запрос (Query) для того, чтобы посмотреть список задач
Также можно заметить, что в столбце Work Item ID в Project появились соответствующие идентификаторы элементов, которые затем могут использоваться для синхронизации данных между Project и TFS
В столбце Длительность вместо планируемых трудозатрат появились нули. Дело в том, что у Work Item в TFS для определения длительностей задач используются другие поля: Original Estimate, Completed Work и Remaining Work. По смыслу длительности в первом приближении наиболее соответствует поле Original Estimate, которое маппится на поле Базовые трудозатраты в Project
И, раз уж мы добрались до маппинга, то есть соответствия между столбцами Project и полями TFS, в двух словах упомянем, как его можно поменять. В одной статье на MSDN описан файл маппинга полей Project, а в другой статье – описан экспорт и импорт этого файла в TFS.
А для того, чтобы разобраться с переносом длительности в трудозатраты, воспользуемся материалами ещё одной статьи с MDSN), т.к. без документации тут уже не разобраться. Зададим, как рекомендуется в этой статье, базовые настройки планировщика в Project (Файл->Параметры->Расписание)
… и определим на основе длительности задач базовые трудозатраты
В итоге колонка Базовые трудозатраты будет заполнена соответствующими значениями
А затем публикуем изменения в TFS.
Так мы и получили в MS Project диаграмму Ганта, а в TFS – набор связанных задач, к которым специалисты могут получить доступ через привычные инструменты, то есть через Visual Studio.
Все пункты наших требований выполнены? Да, в TFS встроена система контроля версий, которую можно также заменить на GIT, так что пункты 4 и 5 автоматически из списка критериев также автоматически поддерживаются в такой схеме. И всё вроде бы хорошо, если бы не
Бочка дёгтя, или Microsoft, ну, как же так?
Критика – не самое приятное занятие, однако в данном случае объективности требует от нас формат статьи. Всё же это не Tutorial по Project и TFS, и мы должны рассмотреть эту связку как средство, которое действительно снижает трудозатраты при работе с планом, а для этого мы должны избежать лишних сложностей в использовании инструментов.
Рассмотрим несколько кейсов, которые возникают при реальном использовании Project и TFS.
Кейс 1. По ошибке добавлен несуществующий баг
Предположим, что в текущую итерацию в TFS добавлен баг, которого в природе не существует. Ошибки случаются, с этим ничего не поделаешь. Или баг оказался не багом, а фичей. Такого у вас не бывало? Аналитик дочитал свою постановку до конца и что-то понял, тестировщик открыл все привязанные к таску файлы, программист решил задать все вопросы, которые его давно мучали (давайте не вспоминать про TDD, пример условный).
Вывод. Если Work Item по ошибке добавлен в TFS, из Project удалить его в автоматическом режиме не выйдет.
Кейс 2. Поменялась длительность итерации
Тоже из опыта… Помните Заказчика из начала статьи? На следующем совещании он сократил сроки на итерацию с двух недель до недели. Понятно, что надо идти и скорее работать, но мы по-хорошему хотим сначала актуализировать план. Зайдём и сократим итерацию в TFS. Как отразилось на тасках? Не отразилось. Таски не понимают, что они не умещаются во временные рамки итераций. Окей, майкрософт, давай загрузим изменения в Project.
И что поменялось? Ничего, Project слышал только о названиях итераций в TFS и ничего не знает о сроках.
Вывод. При изменении сроков итерации разбираться со сроками по таскам придётся в ручном режиме.
Кейс 3. Обобщение проблемы: репланнинг
Замечу, что здесь, на Хабре-Мегамозге, есть прекрасная статья пользователя ganouver, в которой он описывает использование Project для управления проектами. В частности, там можно прочитать про балансировку плана, хитроумные тактики борьбы с Project, а в комментариях найти фразу о том, что
И ещё в его статье встречается высказывание, которое так же хорошо описывает управление разработкой, как Том Кайт описывает СУБД Oracle:
Помимо изменения типов Work Item, удаления лишних задач и т.п., в реальном проекте план может поменяться почти полностью, как по составу тасков в высокоуровневых задачах (стори), так и по длительности и составу итераций. Что предлагает нам Project и TFS, чтобы учесть эти изменения, морфировать таски, сбалансировать заново план, посчитать ресурсы, учитывая изменения в длительности итераций и подготовить новый план по релизам? Ничего не предлагает.
Заключение
Решение от Microsoft для управления проектами и разработкой ПО в виде совместного использования продуктов Project + TFS + Visual Studio может использоваться для однократного планирования работы и плохо подходит для постоянного автоматизированного репланнинга.
Размышляя над тем, стоит ли публиковать статью с выводом о том, что рассматриваемый стек технологий Project + TFS не очень подходит для решения поставленной задачи, я решил, что отрицательный опыт – это тоже опыт, и он, по крайней мере, позволит читателям сделать свой выбор.
Итак, решать задачу полного управления разработкой на этих инструментах можно лишь при первом составлении плана и затем на основе полуавтоматизированного труда руководителя или его помощника, при этом любой репланнинг будет отнимать время на рутинные операции.
В следующих статьях рассмотрим другие наборы инструментальных средств, первыми кандидатами являются Jira и Redmine.
Team Foundation Server (сокр. TFS) — продукт корпорации Microsoft, представляющий собой комплексное решение, объединяющее в себе систему управления версиями , сбор данных, построение разработке программного обеспечения . Данный продукт доступен как в виде отдельного приложения, так и в виде серверной платформы для
Содержание
Архитектура [ ]
3-уровневая архитектура Team Foundation Server
Team Foundation Server работает по трёхуровневой архитектуре: клиентский уровень, прикладной уровень и уровень данных. Клиентский уровень используется для создания и управления проектами, а также для доступа к хранимым и управляемым элементам проекта. На этом уровне TFS не содержит никаких пользовательских интерфейсов, но предоставляет SQL Server 2005 Standard Edition, обеспечивает сервисы постоянного хранения данных для репозитория документов. Уровень данных и уровень приложений могут существовать на различных физических или виртуальных серверах при использовании Windows Server 2003 или более специализированных версий. Уровень данных не взаимодействует с клиентским уровнем напрямую, только через прикладной уровень.
TFS сам по себе не содержит пользовательского интерфейса для выполнения подобных заданий. Подобные возможности предоставляются за счет среды разработки Контроль исходного кода (Source control) [ ]
Team Foundation Server реализует репозиторий управления исходным кодом , называемый Team Foundation Version Control (TFVC). В отличие от предыдущего решения Microsoft по контролю кода, Visual SourceSafe (VSS), которое основывалось на механизме файлового хранения, Team Foundation хранит весь код, равно как и запись обо всех изменениях кода в базе данных под управлением SQL Server. Поддерживаются такие особенности, как например, одновременная множественная блокировка кода для изменения (multiple simultaneous check-outs) (то есть один и тот же файл одновременно могут редактировать несколько человек), разрешение конфликтов, откладывание внесения изменений (shelving) (здесь имеется в виду сохранение набора запланированных изменений без их подтверждения в системе контроля версий, причём другие пользователи могут видеть эти наборы, но доступа к ним без явно предоставленного разрешения не получат), Отчётность (Reporting) [ ]
Reporting — ещё один основной компонент Team Foundation Server. При помощи него можно создавать множество отчётов на основе объединения информации о рабочих элементах, наборах изменений, информации, поставляемой Team Build, и результатов тестирования от Test Agents. Например, уровень изменений кода за определенный временной промежуток, списки ошибок, не имеющих тестовых наборов, повторения ранее пройденных тестов и т. д. Отчёты, созданные при помощи SQL Server Reporting Services , можно экспортировать в нескольких различных форматах, включая Excel, Портал проекта (Project portal) [ ]
Исходя из проектной основы, TFS также создает SharePoint-сайт для проекта, который может использоваться для отслеживания прогресса проекта, наблюдения за рабочими элементами и документами, представленными в библиотеке проекта. На сайте также можно просматривать созданные отчёты. TFS можно применять в качестве центра связи, то есть пользователи, связанные с определенным проектом, могут использовать сайт для общения или взаимодействия друг с другом. Комментарии могут связываться с различными элементами. Для каждого проекта, в зависимости от его свойств, TFS использует заранее предопределенные шаблоны, указываемые при создании сайта. Такие шаблоны могут настраивать (редактировать) администраторы TFS.
Shared services [ ]
TFS обеспечивает поддержку множества сервисов, которые могут быть использованы для интеграции с посторонними приложениям, как например, IDE и Team build [ ]
На данный момент существуют две версии TeamBuild, причём каждая версия соответствует устанавливаемой версии TFS. Впрочем, они вполне легко настраиваются.
TFSBuild.proj — файл, управляющий TeamBuild. Язык Team Build схож с языком Ссылки [ ]
-
(MSDN) (Описание книги на сайте онлайн-магазина Amazon) (MSDN) (онлайн база знаний) (на русском языке)
Шаблон:Нет источников Шаблон:Программное обеспечение для управления проектами
Читайте также: