Team Foundation Server 2017

Last Update: 25.09.2017

Последние обновления см. на странице Заметки о выпуске на английском языке.

Дата выпуска: 16 ноября 2016 г.

Последние обновления см. на странице Заметки о выпуске на английском языке.

Сегодня мы с радостью сообщаем о выпуске Team Foundation Server 2017. Этот новый выпуск включает последние улучшенные и принципиально новые функциональные возможности. Обратите внимание, что требования для Team Foundation Server 2017 изменились. Дополнительные сведения можно найти на странице Требования к Team Foundation Server и совместимость. Если это не те заметки о выпуске, которые вы ожидали увидеть, обратите внимание, что перед вами заметки о выпуске для самой последней версии.

Скачать: Team Foundation Server 2017

Дополнительные сведения о связанных загружаемых файлах см. на странице Загрузки.

Новые возможности

Известные проблемы


Новые возможности

Поиск кода

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

"Поиск кода" — это универсальное решение для анализа и правки программного кода. С его помощью вы можете смотреть определения и примеры использования API, находить описания ошибок по их тексту и решать многие другие задачи (рис. 1).

Поиск кода предлагает следующие возможности:

  • Поиск по одному или нескольким проектам
  • Семантическое ранжирование
  • Расширенная фильтрация
  • Совместная работа с кодом

Code Search

Рис. 1. Поиск кода

Дополнительные сведения см. в статье Поиск по всему коду.

Управление пакетами

С помощью пакетов можно совместно использовать код в организации: составить большой продукт, разработать несколько продуктов на основе общей инфраструктуры или создать многократно используемые компоненты и библиотеки и предоставить к ним общий доступ. Функция управления пакетами (рис. 2) упрощает совместную работу с кодом. Она предоставляет размещение для ваших пакетов, позволяет открывать к ним доступ для выбранных вами пользователей и легко работать с пакетами в Team Build и Release Management.

Она избавляет от необходимости размещать отдельный сервер NuGet или общую папку, располагая пакеты NuGet непосредственно в Team Foundation Server. Она обеспечивает лучшую в своем классе поддержку клиентов NuGet 3.x, а также поддержку устаревших клиентов NuGet 2.x. Эта функция идеально работает с существующей инфраструктурой, группами и разрешениями TFS, поэтому не требуется синхронизировать удостоверения, управлять группами в нескольких местах и т. д. Она также легко интегрируется с Team Build, что позволяет создавать и использовать пакеты в ходе рабочих процессов непрерывной интеграции.

Подробности см. в разделе Обзор управления пакетами.

Рис. 2. Управление пакетами

Усовершенствования Agile

В версии Team Foundation Server 2017 мы добавили новые функции и возможности в рабочие элементы и канбан-доски.

Новая форма рабочего элемента

Новая форма рабочего элемента (рис. 3) теперь выглядит и работает совсем по-другому. В нее также добавлено несколько новых замечательных функций.

  • Возможность широкого обсуждения рабочего элемента.
  • Поддержка перетаскивания для вложений.
  • Улучшенный интерфейс журнала (Журнал и аудит).
  • Улучшенная интеграция кода и сборки.
  • Выделение тем или иным цветом в зависимости от состояния.
  • Гибкий дизайн.
Примечание

Новая форма рабочего элемента используется по умолчанию только для новых коллекций. При переносе существующей коллекции вам потребуется включить новую форму рабочего элемента в параметрах администратора. Дополнительные сведения см. в разделе Управление развертыванием новой веб-формы.

Рис. 3. Новая форма рабочего элемента

Отслеживание рабочего элемента

Теперь вы можете настроить оповещения для отслеживания изменений в конкретном рабочем элементе. Для этого просто нажмите в форме новую кнопку "Отслеживать" (рис. 4). Если включено отслеживание рабочего элемента, вы будете получать уведомление при каждом изменении рабочего элемента, включая обновления полей, ссылок, вложений и комментариев.

Рис. 4. Отслеживание рабочего элемента

Дополнительные сведения см. в статье Отслеживание рабочего элемента.

Динамические обновления канбан-доски

Канбан-доски теперь стали динамическими!

Вам приходилось нажимать клавишу F5 в течение дня, чтобы выяснить, что происходит с вашей канбан-доской? Попробуйте использовать показанный ниже значок (рис. 5).

Рис. 5. Динамические обновления канбан-доски

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

Дополнительные сведения см. в статье Основы работы с канбан-досками.

Усовершенствования контрольных списков

Мы внесли ряд улучшений в работу контрольных списков.

Элементы контрольных списков теперь отображаются в виде гиперссылок (рис. 6). Можно щелкнуть заголовок, чтобы открыть форму рабочего элемента.

Рис. 6. Гиперссылки в контрольных списках

Теперь контрольные списки также поддерживают контекстные меню, позволяющие открывать, изменять или удалять элементы списка (рис. 7).

Рис. 7. Контекстное меню контрольного списка

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

Детализация на досках функций и ситуаций

Теперь вы можете более детально работать с досками функций и ситуаций (рис. 8). Формат контрольного списка позволяет легко помечать работы как завершенные и дает удобное общее представление о завершенных и незавершенных делах.

Рис. 8. Детализация на досках ситуаций

Дополнительные сведения см. в статье Функции и ситуации на канбан-досках.

Включение и отключение заметок на доске

Мы предлагаем расширенное управление дополнительной информацией, которая отображается на картах ваших досок. Теперь вы можете выбирать заметки, которые хотите видеть на картах канбана (рис. 9). Просто снимите флажок заметки — и она исчезнет с карты на канбан-доске. Первые две заметки здесь — это дочерние рабочие элементы (в данном примере это Tasks) и Tests.

Рис. 9. Включение и отключение заметок на досках

Дополнительные сведения см. в статье Настройка карт.

Команда "Удалить форматирование"

Мы добавили новую команду к элементам управления форматированием текста в рабочих элементах, которая позволяет удалить все форматирование для выделенного текста. Меня, например, в прошлом очень раздражало, когда я копировал и вставлял в это поле текст с форматированием, которое нельзя было отменить (или удалить). Теперь можно просто выделить нужный текст, нажать на панели инструментов кнопку "Удалить форматирование" (или нажать клавиши CTRL + ПРОБЕЛ), и текст вернется в формат по умолчанию.

Фильтрация на канбан-доске

Настраивайте канбан-доски под себя, используя фильтры для пользователей, итераций, типов рабочих элементов и тегов (рис. 10). Эти фильтры сохраняются, так что вы можете просматривать свои персонализированные доски даже при подключении с разных устройств.

Рис. 10. Фильтрация на канбан-доске

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

Дополнительные сведения см. в статье Фильтрация на канбан-доске.

Путь итерации по умолчанию для новых рабочих элементов

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

Дополнительные сведения см. в статье Настройка области и путей итерации.

Элемент управления "флажок"

Теперь в ваши рабочие элементы можно добавлять элемент управления "флажок" (рис. 11). Этот новый тип поля (Boolean) имеет все свойства обычных полей, и его можно добавить к любому типу в процессе. При отображении на картах или в результате запроса значение показывается как True или False.

Рис. 11. Элемент управления "флажок"

Дополнительные сведения см. в статье Настройка поля.

Массовое редактирование тегов

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

Рис. 12. Диалоговое окно массового редактирования

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

Новые точки расширения

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

Мы предоставили новую точку расширения для невыполненной работы. Расширения могут отображать свою информацию в панели справа, где сейчас находятся сведения о сопоставлении и работе (рис. 13).

Рис. 13. Точки расширения для невыполненной работы

Дополнительные сведения о расширениях см. в статье Точки расширения.

Усовершенствования электронной почты

Мы значительно улучшили форматирование и полезность оповещений о рабочих элементах, средств отслеживания, а также сообщений электронной почты @mention, отправляемых TFS (рис. 14). Сообщения электронной почты теперь включают типовой заголовок, четкий призыв к действию и имеют улучшенное форматирование, чтобы сведения в сообщении электронной почты было проще понимать и использовать. Кроме того, все эти сообщения электронной почты разрабатываются так, чтобы они хорошо отображались на мобильных устройствах.

Рис. 14. Усовершенствования электронной почты

Дополнительные сведения см. в статье Оповещения рабочих элементов.

Шаблоны рабочих элементов

Мы добавили возможность создавать форматированные шаблоны рабочих элементов непосредственно в веб-интерфейсе (рис. 15). Ранее эта возможность в ней была очень ограничена, и таким способом шаблоны можно было создавать только через функциональный инструмент Visual Studio. Теперь команды разработчиков могут создавать наборы шаблонов для быстрого изменения стандартных полей и управлять ими.

Рис. 15. Шаблоны рабочих элементов

Дополнительные сведения см. в статье Шаблоны рабочих элементов.

Интеграция с Project Server больше не поддерживается

В Team Foundation Server 2017 и более поздних версиях больше не поддерживается интеграция с Project Server. При обновлении базы данных TFS с настроенной интеграцией с Project Server до версии-кандидата 2 вы получите следующее предупреждение.

Мы обнаружили, что для этой базы данных настроена интеграция с Project Server. В Team Foundation Server 2017 и более поздних версиях больше не поддерживается интеграция с Project Server.

После обновления интеграция с Project Server перестанет работать.

В дальнейшем мы будем опираться на интеграционные решения партнеров.

Дополнительные сведения об этом изменении см. в статье Synchronize TFS with Project Server (Синхронизация Team Foundation Server с Project Server).

Усовершенствования панелей мониторинга и мини-приложений

В Team Foundation Server 2017 были усовершенствованы некоторые мини-приложения, например "Плитка запроса" и "Запрос на включение внесенных изменений".

Изменился каталог мини-приложений

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

Рис. 16. Каталог мини-приложений

Дополнительные сведения см. в статье Каталог мини-приложений.

Обновления мини-приложений

Мини-приложение "Плитка запроса" теперь поддерживает до 10 условных правил и позволяет выбирать цвета (рис. 17). Это очень удобно, когда нужно использовать эти плитки как ключевые показатели эффективности для определения работоспособности или необходимых действий.

Рис. 17. Обновление панелей мониторинга

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

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

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

В мини-приложении "Члены команды" стало проще добавлять в команду участников (рис. 18).

Рис. 18. Обновление мини-приложений

Теперь команды могут настроить размер мини-приложения "Результаты запроса", отображаемого на панели мониторинга, для вывода большего количества результатов.

Мини-приложение "Обзор спринта" было изменено с целью облегчить для команд контроль над собственным графиком.

Мини-приложение "Назначено мне" позволяет пользователям легко работать с назначенными им заданиями, не покидая панель мониторинга (рис. 19). С помощью этого мини-приложения администраторы команды смогут добавить эту функцию на свои панели мониторинга, сэкономив 16 щелчков мышью; нет переключения контекста или необходимости что-либо вводить. Пользователи смогут просматривать и фильтровать назначенные им задания, а также управлять ими в контексте мини-приложения.

Рис. 19. "Назначено мне"

REST API панелей мониторинга

Теперь вы можете использовать интерфейсы REST API, чтобы добавлять, удалять и получать сведения на панели мониторинга программными средствами. Эти интерфейсы API также позволяют добавлять, удалять, обновлять, заменять и получать сведения о мини-приложении или списке мини-приложений на панели мониторинга. Соответствующую документацию см. в онлайн-документации Visual Studio.

Права для панелей мониторинга

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

Дополнительные сведения см. в статье Панели мониторинга.

Усовершенствования Git

Для версии Team Foundation Server 2017 был внесен ряд существенных изменений в Git. Эти изменения включают модернизированную страницу ветвей и новый параметр для "сжатого слияния".

Модернизированная страница ветвей

Страница ветвей была полностью перестроена. На ней имеется сводка "Мои", где собраны все ветви, которые вы создали, добавили в избранное или в которые вы что-то отправляли (рис. 20). Для каждой ветви показывается состояние ее сборок и запросов на включение внесенных изменений, а также другие команды, например "Удалить". Если в имени ветви присутствует косая черта, например "features/jeremy/fix-bug", то она отображается в виде дерева, что позволяет легко просматривать большой список ветвей. Если имя ветви известно, ее можно быстро найти поиском.

Рис. 20. Новая страница ветвей

Дополнительные сведения о ветвях см. в статье Управление ветвями.

Новые запросы на включение внесенных изменений

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

Дополнительные сведения см. в статье Проверка кода с помощью запросов на включение внесенных изменений.

Переработанный пользовательский интерфейс

При открытии запроса вы сразу же обратите внимание на новый интерфейс (рис. 21). Мы изменили заголовок, так чтобы он включал все критические состояния и действия. Теперь они доступны из любого представления в программе.

Рис. 21. Заголовок запроса на включение внесенных изменений

Обзор

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

Рис. 22. Обзор запроса на включение внесенных изменений

Файлы

Самая заметная новая функция в этом выпуске — это возможность просматривать в запросе на включение внесенных изменений предыдущие обновления (рис. 23). В предыдущих предварительных версиях мы добавили функцию для отслеживания комментариев при обновлении запроса на включение внесенных изменений. Однако понять, что происходит между обновлениями, не всегда легко. В представлении "Файлы" теперь можно увидеть конкретные изменения, которые произошли при каждой отправке нового кода в запрос на включение внесенных изменений. Это очень удобно, если вы получили отзыв на какой-либо код и хотите увидеть, как изменился именно этот код без учета всех остальных изменений.

Рис. 23. Файлы запроса на включение внесенных изменений

Обновления

Новое представление "Обновления" позволяет увидеть, как запрос на включение внесенных изменений меняется с течением времени (рис. 24). Если в представлении "Файлы" показывается, как изменялись файлы с течением времени, то в представлении "Обновления" отображаются фиксации кода, добавленные в каждом изменении. В случае принудительной отправки в представлении "Обновления" будут по-прежнему отображаться предыдущие обновления в порядке их возникновения.

Рис. 24. Обновления запроса на включение внесенных изменений

Комментарии (теперь с разметкой) и эмодзи

Вам доступны все возможности форматирования Markdown во всех обсуждениях, в том числе подсветка синтаксиса в коде, вставка ссылок, изображений и эмодзи (рис. 25). Интерфейс элементов управления для комментирования также был улучшен. Теперь можно одновременно редактировать (и затем сохранить) несколько комментариев.

Рис. 25. Комментарии к запросу на включение внесенных изменений

Добавление и удаление рецензентов в запросах на включение внесенных изменений

Теперь стало проще добавлять и удалять рецензентов в запросах на включение внесенных изменений. Чтобы добавить рецензента или группу в запрос на включение внесенных изменений, просто введите соответствующее имя в поле поиска в разделе "Рецензенты". Чтобы удалить рецензента, наведите мышь на его плитку в разделе "Рецензенты" и нажмите кнопку со значком "X" (рис. 26).

Рис. 26. Добавление рецензентов в запросы на включение внесенных изменений

Улучшенная прослеживаемость сборок и запросов на включение внесенных изменений

Прослеживаемость между сборками и запросами на включение внесенных изменений была улучшена, и теперь можно легко переходить от запроса на включение внесенных изменений к сборке и обратно. В представлении сведений о сборке для сборки, инициированной запросом на включение внесенных изменений, в источнике теперь будет отображаться ссылка на запрос на включение внесенных изменений, который поставил эту сборку в очередь. В представлении определений сборок любая сборка, инициированная запросом на включение внесенных изменений, будет содержать ссылку на запрос на включение внесенных изменений в столбце "Triggered By" ("Инициировано"). Наконец, в представлении обозревателя сборок все запросы на включение внесенных изменений будут перечислены в исходном столбце.

Отслеживание комментариев в запросах на включение внесенных изменений

Теперь в запросах на включение внесенных изменений в VSTS комментарии отображаются слева в соответствующей строке файла, даже если файл был изменен после добавления комментариев. Раньше комментарии всегда отображались в той строке файла, куда они были изначально добавлены, даже если содержимое файла изменялось. Другими словами, комментарий в строке 10 всегда отображался в строке 10. В соответствии с последними усовершенствованиями при изменении кода расположение комментария меняется, чтобы не обмануть ожидания пользователя. Если комментарий был добавлен в строке 10, а потом в начало файла были добавлены две новые строки, комментарий будет отображаться в строке 12.

Ниже приведен пример того, что случится с комментарием в строке 13 после изменения файла (рис. 27).

Рис. 27. Отслеживание комментариев

Изначально комментарий находился на строке 13. В результате сдвига эта строка стала 14-й, и предназначенный для нее комментарий теперь отображается там, где и ожидается, — тоже в строке 14 (рис. 28).

Рис. 28. Отслеживание комментариев при изменении

Автоматическое завершение запросов на включение внесенных изменений, ожидающих обработки политиками

Команды разработчиков, которые используют политики ветвей (https://www.visualstudio.com/en-us/docs/git/branch-policies) для защиты своих ветвей, может заинтересовать действие автоматического завершения. Очень часто автор запроса на включение внесенных изменений готов выполнить слияние для своего запроса, но вынужден ожидать окончания сборки, чтобы нажать кнопку "Завершить". В других случаях сборка проходит, но какой-то из рецензентов не дал своего окончательного утверждения. В этих случаях функция автозавершения позволяет автору запроса сделать так, чтобы запрос завершился сам, как только все политики будут утверждены (рис. 29).

Рис. 29. Автозавершение

Как и при завершении вручную, автор может сам настроить сообщение, которое будет появляться при фиксации слияния, и выбрать нужные параметры слияния (рис. 30).

Рис. 30. Диалоговое окно автозавершения

После настройки автозавершения в запросе на включение внесенных изменений появится баннер, сообщающий о том, что включено автозавершение и оно ожидает готовности политик (рис. 31).

Рис. 31. Подтверждение автозавершения

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

Запросы на включение внесенных изменений сжатого слияния

Теперь при выполнении запроса на включение внесенных изменений вы можете выполнять сжатое слияние (рис. 32). В этом случае создается одна фиксация, содержащая изменения из тематической ветви, которые будут применены к целевой ветви. Самое заметное различие между обычным слиянием и сжатым слиянием состоит в том, что фиксация сжатого слияния будет иметь только одну родительскую фиксацию. Это будет означать более простой хронологический график, так как все промежуточные фиксации, выполненные в тематической ветке, не будут доступны в итоговом графике фиксации.

Рис. 32. Запрос на включение внесенных изменений со сжатым слиянием

Дополнительные сведения см. в статье Запросы на включение внесенных изменений сжатого слияния.

Прослеживаемость фиксации

Состояние сборки (успех или сбой) теперь четко видно в представлениях "Обозреватель кода" и "Сведения о фиксации" (рис. 33). Более подробные сведения можно получить, просто щелкнув кнопкой мыши, поэтому вы всегда будете знать, прошли изменения в фиксации сборку или нет. Вы также можете настроить, какие сборки сообщают о состоянии, в параметрах репозитория для определения сборки. Кроме того, теперь в представлении "Сведения о фиксации" предлагаются более подробные сведения о внесенных изменениях. Если вы используете запросы на включение внесенных изменений для слияния изменений, то увидите ссылку на запрос на включение внесенных изменений, который внес изменения в главную ветвь (или в случае фиксации слияния — на запрос, который его создал). Когда изменения достигнут главной ветви, появится ссылка на ветвь для подтверждения того, что изменения были включены.

Рис. 33. Прослеживаемость фиксации

Просмотр файлов Git LFS в Интернете

Если вы уже работали с большими файлами (аудио, видео, наборами данных и т. д.) в Git, то знаете, что хранилище больших файлов (LFS) Git заменяет эти файлы указателями в Git, сохраняя содержимое файла на удаленном сервере. Теперь можно просматривать все содержимое этих больших файлов, просто щелкнув нужный файл в репозитории.

Дополнительные сведения см. в статье Управление большими файлами с помощью Git.

Вы можете легко делиться сегментами кода с помощью ссылок на код (рис. 34). Просто выделите текст в файле и щелкните значок ссылки. Будет скопирована ссылка на выделенный код. При просмотре кем-либо этой ссылки выделенный вами код будет иметь золотистый фон. Это работает даже при выделении части строки.

Рис. 34. Отправка ссылок на код

API состояния

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

Рис. 35. API состояния

Значки для типов файлов

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

Рис. 36. Примеры типов файлов

Добавление файла сведений при создании репозитория

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

Рис. 37. Добавление файла сведений

Усовершенствования сборок

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

Обновленная вкладка очереди сборок

Мы обновили дизайн страницы "В очереди". Теперь на ней отображается более длинный список сборок, которые выполняются или находятся в очереди, в более удобном формате (рис. 38).

Рис. 38. Вкладка очереди сборок

Подробнее см. в статье Администрирование системы сборки.

Указание порядка и столбца в расширениях результатов сборки

Теперь вы можете указывать столбец, в котором будут отображаться расширения для раздела результатов сборки, а также порядок, в котором расширения будут появляться (рис. 39). Представление результатов имеет два столбца, и все расширения будут в первом столбце по умолчанию. Примечание. Все сторонние расширения будут отображаться после включенных нами разделов результатов сборки.

Рис. 39. Столбец и очередность для сборки

От сборки в номер строки

Теперь вы можете переходить от ошибки сборки в строку кода, в которой она возникла. Глядя на последнюю ошибку в основной сборке, которую мы используем у себя для политики запросов на включение внесенных изменений, вы увидите следующее (рис. 40):

Рис. 40. От сборки к номеру строки

Представление журналов сборок поддерживает журналы гораздо большего размера

Предыдущее представление журналов поддерживало только журналы до 10 000 строк. Новое средство просмотра построено на основе редактора Monaco, используемого в VS Code, и будет поддерживать журналы до 150 000 строк.

Шаблоны сборок Java

Мы упростили для разработчиков Java начало работы со сборкой, добавив шаблоны сборок для Ant, Maven и Gradle (рис. 41).

Рис. 41. Шаблоны сборок Java

Дополнительные сведения о шаблонах см. в статье Этапы сборки.

Задачи для сборок Xamarin

Мы внесли несколько значительных усовершенствований в поддержку Xamarin.

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

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

Интеграция Docker для управления сборками и выпусками

Воспользуйтесь возможностью сборки образов Docker и отправки их в Docker Hub, включив их в рабочий процесс непрерывной интеграции (рис. 42). Затем разверните эти образы на нескольких узлах Docker в рамках Release Management. Расширение Marketplace добавляет все типы конечных точек служб и задачи, необходимые для работы с Docker.

Рис. 42. Образы Docker

Результаты SonarQube в представлении запросов на включение внесенных изменений

Если сборка, запущенная для слияния запроса на включение внесенных изменений, содержит задачи SonarQube в MSBuild, теперь вы сможете просматривать проблемы анализа нового кода в виде комментариев к запросу (рис. 43). Этот интерфейс работает для любого языка, для которого установлен подключаемый модуль на сервере SonarQube. Дополнительные сведения см. в записи блога Интеграция проблем анализа кода SonarQube в запрос на включение внесенных изменений.

Рис. 43. Запросы на включение внесенных изменений с SonarQube

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

Теперь вы можете выбирать, какие определения сборок сообщают свое состояние обратно в API состояния Git. Это особенно полезно, если имеется много определений, выполняющих сборку конкретного репозитория или ветви, но существует только один элемент, отражающий действительную работоспособность.

Дополнительные сведения см. в руководстве Справочная документация по REST API сборки.

Поддержка Build vNext в комнатах команд

Пользователи всегда могли добавлять уведомления о сборках XAML в комнате команды. Теперь они также могут получать уведомления из Build vNext после завершения сборки.

Включение фильтров пути для триггеров непрерывной интеграции Git

Триггеры CI для размещенных репозиториев Git могут включать или исключать определенные пути. Это позволяет настроить определение сборки таким образом, чтобы сборка выполнялась только при изменении файлов в заданных папках (рис. 44).

Рис. 44. Триггеры непрерывной интеграции в Git

Усовершенствования управления выпусками

С появления интегрированной возможности веб-управления выпусками в Team Foundation Server 2015 в нее внесен ряд усовершенствований.

Клонирование, экспорт и импорт определений выпусков

Мы добавили в центр выпусков возможность клонирования, экспорта и импорта определений выпусков без необходимости установки расширения (рис. 45).

Рис. 45. Команды клонирования и экспорта на странице сводки по выпускам

Дополнительные сведения см. в статье Клонирование, экспорт и импорт определения выпуска.

Результаты теста отображаются в сводной информации о выпуске

На странице сводки о выпуске мы включили точку публикации для внешней службы для отображения сведений о среде.

В Team Services эта функция используется для отображения сводки по результатам тестов при их выполнении в среде выпуска (рис. 46).

Рис. 46. Результаты тестов в сводке выпуска

Дополнительные сведения см. в статье Общие сведения о представлении сводки для выпуска.

Передача маркеров OAuth в скрипты

Чтобы выполнить настраиваемый скрипт PowerShell, который вызывает API REST в Team Services, возможно, для создания рабочего элемента или запроса сведений в сборке в него необходимо передать маркер OAuth.

В настройках среды доступен новый параметр, позволяющий выполнять в среде сценарии как задачи для доступа к текущему маркеру OAuth (рис. 47).

Рис. 47. Передача маркеров OAuth в сценарии

Дополнительные сведения см. в статье Общие параметры среды.

См. простой пример, как получить определение сборки (рис. 48):

Рис. 48. Пример скрипта с использованием передаваемого маркера OAuth

Запуск при частично успешных развертываниях

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

Если задача с таким параметром завершится сбоем, в определении сборки отобразится результат Сборка выполнена частично.

Теперь такое же поведение наблюдается в определениях выпуска. При невыполнении задачи отобразится общий результат "Release partially succeeded" (Выпуск выполнен частично) (рис. 49).

Рис. 49. В сводке по выпускам частично выполненные выпуски выделяются оранжевым цветом

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

Но теперь вам доступен новый параметр для всех сред выпуска, позволяющий сделать так, что Release Management будет запускать выпуск и в последующих средах, даже если выпуск в предыдущей среде выполнен лишь частично (рис. 50).

Рис. 50. Задание параметра для запуска при частично выполненном выпуске

Дополнительные сведения см. в статье Триггеры среды развертывания.

Использование артефактов, которые хранятся в GitHub, напрямую

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

Теперь то же самое можно выполнить для кода, хранящегося в репозитории GitHub (рис. 51).

Рис. 51. Связывание кода в репозитории GitHub с определением выпуска

Дополнительные сведения см. в статье Источники TFVC, Git и GitHub.

Развертывание веб-приложений с помощью ARM

Доступна новая версия задачи развертывания веб-приложений Azure, которая называется Развертывание веб-приложений AzureRM (рис. 52).

Она использует MSDeploy и подключение конечной точки службы Azure Resource Manager. Эта задача предназначена для развертывания веб-заданий Azure и приложений Azure API, а также веб-приложений на основе ASP.NET 4, Node и Python.

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

В будущих версиях могут появиться дополнительные функции, например преобразования конфигураций (рис. 52).

Рис. 52. Развертывание веб-приложений с помощью ARM

Группы задач

Группа задач позволяет объединить уже заданную в сборке или в определении выпуска последовательность задач в одну задачу для многократного использования. Ее можно будет добавлять в сборку или в определение выпуска так же, как и любую другую задачу (рис. 53).

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

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

Рис. 53. Связывание кода в репозитории GitHub с определением выпуска

Дополнительные сведения см. в статье Группы задач.

Обратимое удаление выпусков

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

Однако прежде чем выпуск будет удален окончательно, он хранится вместе со своим определением в течение конкретного периода (обычно 14 дней).

На протяжении этого времени он отображается на вкладке Удалено списков обзора и сведений.

Чтобы восстановить любой из этих выпусков, откройте контекстное меню и выберите Отменить удаление (рис. 54).

Undelete releases

Рис. 54. Отмена удаления выпусков

Дополнительные сведения см. в статье Восстановление удаленных выпусков.

Хранение выпусков и сборок для каждой среды

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

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

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

Кроме того, связанную с выпуском сборку можно хранить в течение того же периода, что и выпуск. Это обеспечит доступность артефактов в случае, если этот выпуск потребуется развернуть повторно (рис. 55).

Retain releases

Рис. 55. Хранение выпусков

Дополнительные сведения см. в статье Хранение выпусков и сборок.

Усовершенствования связанных артефактов

Две новые функции упрощают работу с артефактами и источниками артефактов.

  • С определением выпуска можно связать несколько источников артефактов (рис. 56). Каждый из артефактов загружается в папку на агенте, который называется псевдонимом источника. Теперь псевдоним источника связанного артефакта можно редактировать. Например, при изменении имени определения сборки можно отредактировать псевдоним источника в соответствии с именем определения сборки.

Linked artifact improvements

Рис. 56. Усовершенствования связанных артефактов

For more details, see [Artifact source alias](https://www.visualstudio.com/en-us/docs/release/author-release-definition/understanding-artifacts#source-alias) documentation.
  • Ряд переменных в формате Build.* (например, Build.BuildId и Build.BuildNumber) доступен для использования в параметрах задачи. Если с выпуском связано несколько источников, теперь эти переменные заполняются значениями из источника артефакта, который указан в качестве основного. Дополнительные сведения см. в статье Переменные артефактов.

Развертывание — задача "Вмешательство вручную"

Теперь можно приостанавливать выполнение во время развертывания в среде.

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

После вмешательства вручную вы также можете отклонить развертывание и запретить выполнение дальнейших действий (рис. 57).

Manual intervention task

Рис. 57. Задача "Вмешательство вручную"

Дополнительные сведения см. в статье Вмешательство вручную.

Сценарии для задачи развертывания базы данных SQL

В задачу Развертывание базы данных SQL Azure (рис. 58) добавлена возможность выполнения SQL-сценариев в базе данных SQL Azure. Сценарии могут иметь вид файла или быть встроенными в задачу.

SQL database deployment task scripts

Рис. 58. Сценарии для задачи развертывания базы данных SQL

Сводка по определению выпуска в мини-приложении панели мониторинга

Закрепите определение выпуска на панели мониторинга. Так все члены команды смогут видеть сводку по выпускам для этого определения.

Дополнительные сведения см. в разделе Добавление информации о выпуске на панель мониторинга.

Развертывание выпусков в среде в определенное время

Хотите, чтобы все развертывания в рабочей среде осуществлялись в полночь? Вы можете задать для среды условие, в соответствии с которым будет выбираться успешное развертывание (или просто последнее развертывание) из другой среды, которое будет запускаться в указанное время (рис. 59).

Schedule release to an environment

Рис. 59. Планирование выпуска в среде

Развертывание на основе условий в нескольких средах

До предыдущей версии можно было выполнять параллельные развертывания (разветвленные), однако нельзя было запустить развертывание в среде на основе состояния нескольких сред (объединенные развертывания). Теперь у вас есть такая возможность.

Дополнительные сведения см. в разделе Параллельные разветвленные и объединенные развертывания.

REST API для управления выпусками

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

Дополнительные сведения см. в справочной документации по API. Некоторые простые примеры использования этих интерфейсов API представлены в записи блога Using ReleaseManagement REST API’s (Использование REST API для управления выпусками).

Интеграция перехватчиков событий

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

Развертывание в национальных облаках Azure

Воспользуйтесь новым параметром среды, чтобы настроить на конечной точке классической службы Azure работу с конкретным облаком Azure. Он включает готовые настройки облака Azure для определенных регионов (Китая и Германии), а также для государственных организаций в США (рис. 60).

Рис. 60. Развертывание в национальных облаках Azure

Дополнительные сведения см. в статье Конечная точка классической службы Azure.

Усовершенствования тестов

В версии Team Foundation Server 2017 существенно усовершенствованы тесты.

Обновленная схема хранилища результатов тестов

В этом выпуске мы переносим артефакты результатов тестов в новую компактную и эффективную схему хранилища. Так как результаты тестов занимают довольно много места в базах данных TFS, эта схема должна помочь уменьшить объем используемого места в хранилище для баз данных TFS. Для клиентов, выполняющих обновление с более ранних версий TFS, результаты тестов будут перенесены в новую схему во время обновления TFS. Это обновление может привести к увеличению времени обновления в зависимости от объема данных результатов тестов, существующих в базах данных. Рекомендуется настроить политику хранения тестов и дождаться включения этой политики и сокращения объема хранилища, используемого результатами тестов, чтобы обновление TFS выполнялось быстрее. После установки TFS, но перед обновлением экземпляра TFS можно использовать средство TFSConfig.exe, чтобы очистить результаты теста. Дополнительные сведения см. в справке по TFSConfig.exe. Если возможность гибкой настройки хранения тестов или очистки их результатов перед обновлением отсутствует, запланируйте соответствующее окно обновления. Дополнительные примеры настройки политики хранения тестов см. в публикации Test result data retention with Team Foundation Server 2015 (Хранение данных результатов тестов в Team Foundation Server 2015).

Усовершенствования центра тестирования

Управление конфигурациями тестов в центре тестирования

Мы включили в пользовательский веб-интерфейс управление конфигурациями тестов, добавив в центр тестирования новую вкладку "Конфигурации" (рис. 61). Теперь вы можете создавать конфигурации тестов и переменные конфигураций тестов и управлять ими в центре тестирования.

Configurations hub

Рис. 61. Центр конфигураций

Дополнительные сведения см. в разделе Create configurations and variables (Создание конфигураций и переменных).

Назначение конфигураций для планов тестирования, наборов тестов и тестовых случаев

Назначать конфигурации стало проще — вы можете задавать конфигурации для планов тестирования, наборов тестов или тестовых случаев непосредственно в центре тестирования (рис. 62). Щелкните элемент правой кнопкой мыши, выберите Назначить конфигурации для ..., и процесс начинается. В центре тестирования также можно использовать фильтр для конфигураций (рис. 63).

Assign Configurations

Рис. 62. Назначение конфигураций

Configurations Filter

Рис. 63. Фильтр конфигураций

Дополнительные сведения см. в разделе Assign configurations to test plans and suites (Назначение конфигураций планам тестирования и наборам тестов).

Столбцы планов тестирования и наборов тестов в области результатов тестирования

Мы добавили в область результатов тестирования новые столбцы, показывающие план тестирования и набор тестов, в котором были получены результаты тестирования. Эти столбцы позволяют увидеть часто необходимый контекст для анализа результатов (рис. 64).

Test Results Pane

Рис. 64. Область результатов тестирования

Порядок тестов в центре тестирования и на картах

Теперь вы можете упорядочивать в центре тестирования тесты, выполняемые вручную (рис. 65), вне зависимости от типа наборов, в которые они включены: это могут быть статические наборы либо наборы на основе требований или запросов. Чтобы изменить порядок тестов, можно просто перетащить один или несколько тестов или воспользоваться контекстным меню. После завершения упорядочивания можно сортировать тесты по полю порядка и затем выполнять их в этом порядке в Web Runner. Вы также можете упорядочивать тесты непосредственно в карте пользовательской истории на канбан-доске (рис. 66). Таким образом, выполнен один из долго ожидающих пунктов, за которые проголосовали пользователи (с 495 голосами) в разделе ручного тестирования.

Order tests

Рис. 65. Упорядочивание тестов

Order tests on card

Рис. 66. Упорядочивание тестов на карте

Упорядочивание наборов тестов в центре тестирования

Команды тестирования теперь могут упорядочить наборы тестов по своему желанию. До этого наборы были просто представлены в алфавитном порядке. Теперь можно изменять порядок наборов в центре тестирования, используя перетаскивание. Возможно как изменение порядка наборов на одном уровне, так и перенос их в другой набор в иерархии (рис. 67). Таким образом удовлетворен этот запрос на обеспечение возможности изменения порядка наборов в разделе ручного тестирования и управления тестовыми случаями.

Рис. 67. Изменение порядка наборов тестов

Поиск пользователей при назначении инженеров-испытателей

Сейчас мы внедряем в разнообразных центрах новые элементы управления "Выбор удостоверения". В рамках этой инициативы мы реализовали в центре тестирования возможность поиска пользователей при назначении тест-инженеров для одного или нескольких тестов (рис. 68). Это очень удобно, если в команде много человек, а в контекстном меню отображается лишь ограниченный набор записей * (рис. 69).

Рис. 68. Поиск пользователей

Assign Users

Рис. 69. Назначение пользователей

Выбор тестируемой сборки

Теперь вы можете выбрать сборку для тестирования, а затем запустить веб-средство выполнения, воспользовавшись функцией "Запуск с параметрами" в центре тестирования (рис. 70). Все ошибки, зарегистрированные во время выполнения, автоматически будут связаны с выбранной сборкой. Кроме того, выходные данные теста будут опубликованы для этой конкретной сборки.

Рис. 70. Выбор сборки

Запуск клиента Microsoft Test Runner из Центра тестирования со сборщиками данных

Теперь вы можете выбрать сборщики данных и сборку, которые будут связаны с тестовым запуском (рис. 71). Это позволяет эффективно запускать Microsoft Test Runner 2017 (клиент) в центре тестирования, не настраивая приведенные выше аспекты в клиенте Microsoft Test Manager. Microsoft Test Runner запускается без открытия всей оболочки Microsoft Test Manager. Его работа будет завершаться по окончании выполнения теста.

Run with options

Рис. 71. Запуск с параметрами

Дополнительные сведения см. в разделе Run tests for desktop apps (Выполнение тестов для классических приложений).

Выбор сборщиков данных и запуск клиента Exploratory Runner из центра тестирования

Теперь можно быстро выбрать сборщики данных и запустить клиент Exploratory Runner 2017 из центра тестирования. При этом их не нужно настраивать в клиенте Microsoft Test Manager. Выберите "Запуск с параметрами" в контекстном меню (рис. 72) основанного на требованиях набора, а затем выберите Exploratory Runner и нужные вам сборщики данных. Клиент Exploratory Runner будет запущен так же, как и клиент Microsoft Test Runner, как описано выше.

Run with Options - XT

Рис. 72. Запуск с параметрами — произвольное тестирование

Настройка результатов тестов для тестов в разных наборах тестов

Мы добавили возможность настраивать результаты для тестов, используемых в разных наборах в одном плане тестирования (рис. 73). При выборе этого параметра и настройке результата теста (пометить этот тест как "Успешный", "Неудачный" или "Заблокированный" из Центра тестирования, средства Web Runner или из карточек на канбан-доске) этот результат будет распространен на все остальные тесты в разных наборах тестов в составе одного плана тестирования с той же конфигурацией. Пользователи могут установить параметр "Настроить результаты тестов" в контекстом меню плана тестирования в Центре тестирования или в диалоговом окне "Общие параметры конфигурации" на странице тестирования канбан-доски. По умолчанию этот параметр отключен, и его нужно включить явным образом, чтобы изменения вступили в силу.

Configure test outcomes

Рис. 73. Настройка результатов тестов

Проверка ошибок из рабочего элемента

Теперь вы можете проверить ошибку, повторно запустив тесты, в которых она была выявлена (рис. 74). Параметр проверки находится в рабочем элементе ошибки в контекстном меню и используется для запуска соответствующего тестового случая в средстве Web Runner. Выполните проверку с помощью средства Web Runner и обновите рабочий элемент ошибки непосредственно в средстве Web Runner.

Verify bugs

Рис. 74. Проверка ошибок

REST API для клонирования плана тестирования или набора тестов

Мы добавили интерфейсы REST API для клонирования планов тестирования и наборов тестов. Вы можете найти их в разделе управления тестированием на нашем сайте интеграции Team Services.

Ход выполнения теста на канбан-картах

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

Inline tests

Рис. 75. Встроенные тесты

Благодаря этой новой возможности вы можете выполнять следующие действия непосредственно из карты на доске.

  • Добавлять тесты.
  • Открывать тесты.
  • Переподчинять тест путем перетаскивания из одной пользовательской истории в другую.
  • Копировать тест в другую пользовательскую историю, используя клавишу CTRL и перетаскивание (для сценариев, где один тест используется для тестирования нескольких пользовательских историй).
  • Обновлять состояние теста, быстро помечая его как Pass/Fail/и т. п.
  • Выполнять тест, запустив его в средстве выполнения тестов Web Test Runner, в котором можно помечать отдельные шаги как пройденные или неудачные, регистрировать ошибки и т. д.
  • Просматривать сводные данные о состоянии, указывающие, сколько тестов было пройдено и сколько остается для этой истории.

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

Переход к набору тестов и плану тестирования из карты

Теперь можно с легкостью перейти к базовому плану тестирования и набору тестов, на базе которых созданы тесты, непосредственно из карточки на канбан-доске. Щелкните ссылку (рис. 76), чтобы перейти в центр тестирования, где можно открыть подходящий план тестирования и выбрать определенный набор для управления этими встроенными тестами.

Traverse to plan/suite

Рис. 76. Переход к плану или набору

Страница "Тесты" в мастере настройки общих параметров канбан-доски

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

Common settings

Рис. 77. Общие параметры

Улучшения средства Web Runner

Добавление вложений для шагов теста во время тестирования вручную

Мы усовершенствовали веб-средство выполнения тестов: теперь оно позволяет вам добавлять вложения для шагов теста при тестировании вручную (рис. 78). Эти вложения для результатов этапов автоматически отображаются во всех ошибках, зарегистрированных во время сеанса, а затем в области результатов тестирования.

Test Step attachments

Рис. 78. Вложения для шагов теста

Снимки и видеозапись экрана, журнал действий с изображениями и информация о системе в веб-средстве выполнения (с браузером Chrome)

В веб-средстве выполнения теперь можно делать снимки экрана и сразу добавлять к ним заметки при использовании Chrome (рис. 79). Кроме того, можно создавать видеозаписи экрана по запросу не только для веб-приложений, но и для классических приложений. Эти снимки экрана и видеозаписи экрана автоматически добавляются в текущий шаг теста. Помимо создания снимков экрана и видеозаписей действий на экране можно настроить ведение журнала действий с изображениями по требованию из веб-приложений. Нужно указать окно обозревателя для записи действий. Все действия в этом окне (на имеющихся или новых открытых вкладках) или в любых новых запущенных дочерних окнах браузера будут автоматически записываться и сопоставляться с шагами теста, выполняемого в Web Runner. Затем эти снимки экрана, видеозаписи экрана и журналы действий с изображениями добавляются к записям об ошибках, зарегистрированным во время выполнения, а также присоединяются к результатам текущего теста. Аналогично, сведения о системе автоматически записываются и включаются в каждую ошибку, зарегистрированную из Web Runner. При этом задействуется возможность из расширения "Тестирование и обратная связь" на основе браузера Chrome.

Web runner using Chrome browser

Рис. 79. Веб-средство выполнения в браузере Chrome

Дополнительные сведения см. в разделе Collect diagnostic data during tests (Сбор диагностических данных во время выполнения тестов).

Ошибки как дочерние элементы — веб-средство выполнения и расширение "Тестирование и обратная связь"

При выполнении в Web Runner тестов, запущенных из карты на доске или из набора на основе требований в центре тестирования, все новые зарегистрированные ошибки теперь будут автоматически создаваться как дочерние для данной пользовательской истории. Аналогично, если вы исследуете пользовательскую историю из расширения произвольного тестирования, все зарегистрированные вами новые ошибки также будут создаваться как дочерние для данной пользовательской истории. Это новое поведение упрощает прослеживаемость по историям и ошибкам. Это применимо только в том случае, если для параметров "Работа с ошибками" на странице "Конфигурация общих параметров" задано значение "Ошибки не отображаются в невыполненных работах и на досках" или "Ошибки отображаются в невыполненной работе и на досках с задачами". Для всех остальных настроек параметра "Работа с ошибками" и некоторых сценариях, таких как добавление в существующую ошибку, уже имеющую заданного родителя, вместо этого будет создана связанная ссылка.

Обновление сведений об ошибках в веб-средстве выполнения

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

Add to existing bug

Рис. 80. Добавление сведений в существующую ошибку

Расширение "Тестирование и обратная связь" — улучшения

Расширение "Тестирование и обратная связь" на основе браузера можно установить из Visual Studio Marketplace. Оно поддерживает Visual Studio Team Services и Team Foundation Server (2015 или более поздней версии).

Изучение рабочих элементов

Теперь вы можете выполнять произвольное тестирование для определенных рабочих элементов (рис. 81). Это позволяет связать выбранный рабочий элемент с выполняющимся сеансом тестирования, а также просматривать условия приемки и описание прямо в расширении. Кроме того, вы можете отслеживать все ошибки и задачи, зарегистрированные для выбранного рабочего элемента, равно как и взаимосвязи между ними. Изучать рабочий элемент можно непосредственно из него самого либо из расширения:

• Непосредственно из рабочего элемента (рис. 81): выберите "Выполнить произвольное тестирование" в контекстном меню, чтобы запустить сеанс произвольного тестирования для конкретного рабочего элемента непосредственно из продукта. Мы добавили точки входа на все карты, таблицы и в центр тестирования.

• Из расширения (рис. 82): выполните поиск рабочего элемента в сеансе произвольного тестирования и свяжите его с выполняющимся сеансом.

XT from card

Рис. 81. Произвольное тестирование из рабочего элемента

Explore work item

Рис. 82. Произвольное тестирование из расширения

Дополнительные сведения см. в статье Explore work items with the Test & Feedback extension (Изучение рабочих элементов с помощью расширения "Тестирование и обратная связь").

Расширение "Тестирование и обратная связь": журналы действий с изображениями, видеозаписи экрана и фиксация данных загрузки веб-страниц

Журнал действий с изображениями. Расширение позволяет всего одним щелчком мыши начать записывать последовательность действий, которая приводит к ошибке. Выберите параметр "Включить журнал действий с изображениями" (рис. 83), чтобы записывать действия, выполняемые с клавиатуры, мыши или сенсорного экрана. Вы сможете добавлять соответствующий текст и изображения непосредственно в ошибки или задачи.

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

Данные о загрузке страницы. Мы добавили новую возможность записи фоновых данных в расширение —запись данных о загрузке веб-страницы. Так же, как журнал действий изображений в фоновом режиме фиксирует действия в исследуемом веб-приложении в виде изображений, функция записи данных о загрузке автоматически фиксирует сведения, касающиеся веб-страницы, для завершения операции загрузки. Вместо того чтобы полагаться на наблюдаемую низкую скорость загрузки веб-страницы, теперь можно объективно оценить эту скорость. После регистрации ошибки помимо мозаичного представления к ошибке также прикрепляется подробный отчет, который может помочь разработчику в начале исследования.

XT Image Action Log

(Рис. 83) Журнал действий с изображениями произвольного тестирования

Создание тестовых случаев на основе данных журнала действий с изображениями

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

XT Create Test Cases

Рис. 84. Создание тестовых случаев для произвольного тестирования

Дополнительные сведения см. в разделе Create test cases (Создание тестовых случаев).

Анализ сеанса произвольного тестирования

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

  • Сводное представление с информацией об исследуемых рабочих элементах, созданных рабочих элементах и владельцах сеансов, а также общее время, затраченное на эти сеансы (рис. 85).
  • Представление с разбивкой, которое можно сводить по исследуемым рабочим элементам, сеансам, владельцам сеансов или не используя ни один из этих параметров. Для любой сводки можно либо просматривать список всех созданных рабочих элементов (ошибок, задач, тестовых случаев), либо переместиться вниз по списку до рабочего элемента конкретного типа.
  • Представление области сведений, отображающее информацию на основе выбора в представлении с разбивкой. Для выбранной строки сводки (например, для исследуемых рабочих элементов) можно в области сведений просматривать ее сводные данные, такие как общее число сеансов, общее время, затраченное на эти сеансы, владельцы сеансов, выполнявшие исследование, а также ошибки, задачи и тестовые случаи, созданные для них, вместе с их состоянием и приоритетом. Для строки выбранного рабочего элемента можно просмотреть его встроенную форму рабочего элемента и внести соответствующие изменения.

XT Session insights

Рис. 85. Анализ сеанса произвольного тестирования

Дополнительные сведения см. в статье Get insights across your exploratory testing sessions (Получение аналитических данных из сеансов произвольного тестирования).

Сеансы произвольного тестирования: просмотр неисследованных рабочих элементов

Помимо возможности просмотреть сведения обо всех исследуемых рабочих элементах в представлении "Недавние сеансы произвольного тестирования", где эти сведения можно отфильтровать по всем или только вашим сеансам за указанный период, теперь мы добавили возможность просмотреть список всех рабочих элементов, которые НЕ были исследованы (рис. 86). Сначала нужно настроить общий запрос необходимых рабочих элементов, после чего на странице сеансов отобразится список всех запрошенных рабочих элементов с разбиением по исследованным и неисследованным элементам в разделе сводки. Кроме того, с помощью сводки с группированием по неисследованным рабочим элементам можно просмотреть список элементов, которые еще не были рассмотрены. Это помогает отслеживать количество описаний функциональности, которые еще не были рассмотрены или для которых еще не выполнено устранение ошибок.

View unexplored WIT

Рис. 86. Просмотр неисследованных рабочих элементов

Комплексный процесс получения отзывов заинтересованных лиц
Запрос на отзыв

Пользователи с базовым уровнем доступа теперь могут напрямую запрашивать у заинтересованных лиц отзывы, касающиеся рабочих функций и актуальных или уже завершенных примеров использования. Для этого используется команда "Запрос на отзыв" в меню рабочего элемента (рис. 87). В открывшейся форме "Запрос на отзыв" можно выбрать заинтересованные лица, отзывы от которых нужно получить, и при необходимости предоставить простой набор инструкций с указанием направлений и областей, представляющих интерес. Эта форма вместе с инструкциями (при их наличии) будет отправлена в виде индивидуального сообщения заинтересованному лицу.

XT Feedback Flow

Рис. 87. Процесс предоставления отзыва при произвольном тестировании

Дополнительные сведения см. в разделе Request feedback from stakeholders (Запрос на отзывы заинтересованных лиц).

Предоставление отзыва

Заинтересованные лица могут ответить на запрос на отзыв, щелкнув ссылку "Предоставить отзыв" в полученном сообщении электронной почты, которая автоматически настроит расширение "Тестирование и обратная связь" (прежнее название — расширение "Произвольное тестирование") с выбранным запросом на отзыв (будет предложено установить расширение, если это еще не сделано). Затем заинтересованные лица могут использовать все возможности записи для регистрации мнений и отправить отзывы в виде ответа, описания ошибки или рабочих элементов задачи. Кроме того, они могут перейти на страницу "Запросы отзывов", чтобы в одном месте просмотреть все полученные ими запросы на отзывы. Они могут выбирать в списке запрос, по которому нужно предоставить отзыв, контролировать ожидающие отзыва запросы (рис. 88), отклоняя их или помечая их как завершенные, а также выбирать между разными типами запросов, используя переключатель (рис. 89).

Provide feedback link

Рис. 88. Ссылка на предоставление отзыва

XT Feedback Flow

Рис. 89. Процесс предоставления отзыва при произвольном тестировании

Дополнительные сведения см. в разделе Provide feedback (Предоставление отзыва).

Добровольный отзыв

Помимо упомянутого выше процесса запроса на отзыв, заинтересованные лица могут также использовать расширение для предоставления добровольного отзыва (рис. 90). Нужно открыть расширение, на странице параметров подключения выбрать режим "Подключено" и подключиться к учетной записи и проекту или группе, которым необходимо отправить отзыв. Затем заинтересованные лица с помощью расширения могут записать свои мнения и отправить отзывы в виде ответа, описания ошибки или рабочих элементов задачи.

Voluntary Feedback

Рис. 90. Добровольный отзыв

Дополнительные сведения см. в разделе Provide voluntary feedback (Предоставление добровольного отзыва).

Улучшение автоматического тестирования

Журналы консоли и длительность тестирования на вкладке тестов в сводке по сборке и выпуску

Журналы консоли результатов теста, которые сохраняются в формате TRX-файлов, извлекаются и публикуются в виде вложений к результатам тестирования (рис. 91). Их можно просматривать на вкладке "Тесты". Загружать TRX-файлы больше не требуется.

Console logs and duration

Рис. 91. Журналы консоли и длительность

Мини-приложение тенденций тестов для сборок

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

'Test result trend' widget

Рис. 92. Мини-приложение "Тенденция в результатах тестирования"

Просмотр состояния тестов в сводке по среде выпуска

Для развертывания приложений и выполнения для них тестов рекомендуется использовать среды выпуска. Теперь на странице сводки по выпускам в разделе "Среды" отображается показатель успешного выполнения тестов в среде выпуска (рис. 93). Как показано на снимке экрана, если при создании среды произошел сбой, вы можете быстро определить, связано ли это с непройденными тестами, просмотрев столбец тестов. Чтобы исследовать непройденные тесты для этой среды, щелкните показатель успешного выполнения, после чего перейдите на вкладку тестов.

Test status with Release Environment summary

Рис. 93. Состояние по тестам в сводке по среде выпуска

Автоматизированный журнал тестирования для ветвей и сред выпуска

Отдельные тесты часто выполняются в нескольких ветвях, средах и конфигурациях. Если такой тест завершается сбоем, важно определить: сбои связаны только с ветвями разработки, например с главной ветвью, или они также влияют на ветви выпуска, которые осуществляют развертывание в рабочей среде. Теперь вы можете визуализировать историю выполнения теста в различных тестируемых ветвях. Для этого откройте вкладку "Журнал" на странице сводки результатов (рис. 94). Аналогичным образом можно выбрать сводку по среде, чтобы визуализировать журнал тестов по различным тестируемым средам выпуска.

Test status with Release Environment summary

Рис. 94. Состояние по тестам в сводке по среде выпуска

Отслеживание для непрерывного тестирования

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

Requirement Quality Widget

Рис. 95. Мини-приложение по выполнению требований

Удаленное тестирование — распределение тестов в зависимости от количества компьютеров

Мы добавили возможность распределения тестов из сборки по удаленным компьютерам с помощью задачи "Запуск функциональных тестов" (рис. 96). В TFS 2015 тесты можно было распространять только на уровне сборки. Эту новую возможность можно активировать с помощью флажка в задаче, как показано ниже.

Task Setting

Рис. 96. Параметры задачи

Автоматическое тестирование для SCVMM и VMware

Пользователи могут динамически настраивать тестовые компьютеры в облаке с помощью Azure или локально с помощью SCVMM или VMware и использовать эти компьютеры для распределенного запуска тестов. Пользователи могут подготовить компьютеры с помощью задач Azure, SCVMM или VMware, а затем выполнить тестирование с помощью задачи "Запуск функциональных тестов".

Анализ SonarQube в задачах Maven и Gradle

Теперь вы можете запускать анализ SonarQube в задачах сборки Maven и Gradle. Для этого установите флажок "Запустить анализ SonarQube" и укажите конечную точку, название проекта SonarQube, ключ и версию проекта (рис. 97).

Run SonarQube Analysis

Рис. 97. Запуск анализа SonarQube

Вы также получите ссылку на проект SonarQube (рис. 98). Вы можете запросить полный анализ для оценки данных о критериях качества и настроить прерывание сборки, если критерии не выполняются.

Run SonarQube Analysis

Рис. 98. Запуск анализа SonarQube

Дополнительные сведения см. в статье The Gradle build task now supports SonarQube analysis (Задача сборки Gradle теперь поддерживает анализ SonarQube).

Усовершенствования Marketplace

Теперь администраторы коллекции проектов могут перейти к Visual Studio Marketplace из Team Foundation Server и установить бесплатные расширения в коллекции командных проектов. Эти расширения автоматически скачиваются из Visual Studio Marketplace, отправляются в Team Foundation Server и устанавливаются в выбранной коллекции командных проектов (рис. 99).

Install Free Extension

Рис. 99. Установка бесплатного расширения

Приобретение и установка платных расширений

Теперь администраторы коллекции проектов могут перейти из Team Foundation Server в магазин Visual Studio Marketplace, приобрести в нем платные расширения и установить их в выбранной коллекции командных проектов (рис. 100). Администратор может оплатить расширения с помощью подписки Azure и выбрать пользователей, которым будут назначены эти расширения. Расширения автоматически скачиваются из Visual Studio Marketplace, отправляются на Team Foundation Server и устанавливаются в выбранной коллекции командных проектов.

Purchase Paid Extension

Рис. 100. Приобретение платного расширения

Дополнительные сведения см.в статье Получение расширений для Team Foundation Server.

Улучшения администрирования

Проверка подлинности Windows

В предыдущих выпусках при настройке развертывания TFS, присоединенного к домену, пользователям приходилось выбирать между поставщиками поддержки безопасности — NTLM и Negotiate — для проверки подлинности Windows. В выпуске 2017 мы удалили этот параметр из процесса настройки. Чтобы продолжить использование проверки подлинности NTLM в выпуске 2017, не требуется выполнять никаких действий. Если вы использовали проверку подлинности Kerberos и хотите работать с ней в выпуске 2017, ничего делать не нужно. Теперь TFS 2017 всегда настраивает поставщиков поддержки безопасности Negotiate и NTLM в указанном порядке. В такой конфигурации проверка подлинности Kerberos будет использоваться там, где это возможно, обеспечивая повышенную безопасность. Если нельзя использовать Kerberos, будет использоваться проверка подлинности NTLM. Мы провели углубленное тестирование, чтобы гарантировать, что данное изменение не окажет негативное влияние на существующие развертывания, использующие проверку подлинности TFS.

Передовые возможности навигации

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

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

Так как это существенное изменение для наших пользователей и итерация этой функции все еще выполняется, новые возможности навигации будут выключены по умолчанию. Если вы хотите опробовать их, перейдите на панель управления в области администрирования Team Foundation Server и выберите параметр Turn on new navigation (Включить новую навигацию). Учтите, что в таком случае новая навигация активируется для всех пользователей на сервере.

Права на переименование командного проекта

Разрешение, определяющее, какие пользователи могут переименовывать командный проект, было изменено. Ранее командный проект могли переименовывать пользователи с разрешением "Изменение сведений на уровне проекта" для этого командного проекта. Теперь предоставление или отмена возможности переименования командного проекта пользователями выполняется с помощью нового разрешения "Переименование командного проекта".

Центр работы на странице параметров администрирования

Мы представили новый центр "Работа" на странице параметров администрирования, объединяющий на одной вкладке общие параметры (рис. 101), итерации и области. После этого изменения пользователи будут видеть четкие различия между параметрами уровня проекта и параметрами группы. Для параметров группы пользователи будут видеть только области и итерации, относящиеся к их группе. На уровне проекта страница параметров будет позволять администраторам управлять областями и итерациями для всего проекта. Кроме того, для путей к областям проекта был добавлен новый столбец с именем "Группы", чтобы администраторы могли быстро и просто определить, какие группы выбрали конкретный путь к области.

Admin work hub

Рис. 101. Центр работы для администратора

REST API конфигурации процессов

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

  • TypeFields: абстракции настраиваемых полей, используемых в гибких средствах. Например, тип поля "Баллы истории" — "Effort" ("Трудозатраты").
  • Определения невыполненной работы: определение, какие рабочие элементы имеются в каждой из невыполненных работ. Это часто запрашиваемый API от клиентов, создающих расширения. С помощью этих данных расширение может узнать, как использовать относящиеся к процессу поля для включения распространенных сценариев в гибких средствах (таких как изменение действия или трудозатраты рабочего элемента, выяснение, какие рабочие элементы включены на заданном уровне невыполненной работы, или определение, идентифицируются ли группы по пути к области или по настраиваемому полю). Дополнительные сведения см. в статье с общими сведениями об использовании.

В выпуске Team Foundation Server 2017 представлена новая возможность для управления группами и членством в группах. Теперь вы можете искать пользователей и группы в Active Directory или на локальном компьютере, используя в качестве условия поиска префикс. Например, введите "Олег Д" или значение атрибута samAccountName (например, "имя_рабочего_домена\olegbdnd") и просмотрите карточку контакта пользователя или группы.

Параметры безопасности пользователя

Управляйте личными маркерами доступа и параметрами SSH в новом разделе "Моя безопасность" (рис. 102). Пользователям, которые управляли открытыми ключами SSH через раздел "Мой профиль", теперь нужно будет переходить для этого к параметрам пользовательской безопасности (рис. 103).

My security

Рис. 102. Моя безопасность

My profile

Рис. 103. Мой профиль

Единый мастер настройки

В предыдущих версиях для настройки развертывания TFS использовалось несколько мастеров настройки: простой и расширенный мастера использовались для настройки нового развертывания, мастер обновления — для обновления рабочей и подготовительной сред, а мастер настройки на уровне приложений — для разнообразных сценариев, в том числе масштабирования имеющегося развертывания, замены уровня приложений новым оборудованием и т. д. В TFS 2017 все эти сценарии объединены в единый мастер настройки сервера, который помогает выполнить каждый из этих сценариев. Все, что вам нужно делать, — выбирать те или иные варианты. Кроме того, в расширенных настройках (обновление подготовительной среды и клонирование имеющегося развертывания) автоматизированы действия, которые раньше выполнялись с помощью tfsconfig.exe, в частности изменение идентификатора сервера, повторное сопоставление строк подключения к базам данных и удаление ссылок на внешние зависимости (для чего раньше использовалась команда tfsconfig.exe PrepareClone).

Новый уровень доступа

Благодаря новой группе Visual Studio Enterprise, добавленной к уровням доступа портала администрирования на серверах Team Foundation Server, можно быстро определить, у кого есть подписка Visual Studio Enterprise. После своего нахождения эти пользователи получат полный доступ ко всем несторонним расширениям TFS, установленным из Visual Studio Marketplace, без дополнительной платы.

Личные маркеры доступа

Теперь к любому серверу Team Foundation Server можно подключиться не только с использованием ключей SSH, но и с помощью личных маркеров доступа (рис. 104). Это удобно, если вы используете платформу Linux или Mac и хотите использовать средства автоматизации и GIT. Личными маркерами доступа можно управлять на странице параметров безопасности пользователя.

Personal Access Tokens

Рис. 104. Личные маркеры доступа

Известные проблемы

Ниже приведен полный список известных проблем в этом выпуске.

Отсутствие средств Power Tools для Team Foundation Server 2017

  • Проблема.

    Для TFS 2017 не выпущены Power Tools.

  • Инструкции по решению:

    Мы рады сообщить, что большинство предыдущих Power Tools были интегрированы в TFS 2017. Редактор шаблонов процесса — он не был интегрирован, но вы можете получить его в Visual Studio Marketplace.

Обновление расширений пользовательских элементов управления

  • Проблема.

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

  • Инструкции по решению:

    См. новый документ Add a custom control to the work item form (Добавление настраиваемого элемента управления в форму рабочего элемента).

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

  • Проблема.

    Пользователи с установленным расширением страницы рабочего элемента, которые экспортируют определение типа рабочего элемента, а затем импортируют его, увидят сообщение об ошибке "Атрибут LayoutMode не объявлен".

  • Инструкции по решению:

    При каждом экспорте определения типа рабочего элемента в элементе PageContribution существует дополнительный атрибут LayoutMode. Прежде чем импортировать определение, найдите режим PageContribution и удалите атрибут LayoutMode. Например, удалите LayoutMode="FirstColumnWide".

Клиенты должны обновить версию LFS Git до 1.3.1 или более поздней версии

  • Проблема.

    Версии LFS Git до 1.3.1 не будут поддерживаться в будущих выпусках.

  • Решение

    Клиентам, использующим LFS Git, настоятельно рекомендуется обновить версию LFS Git до 1.3.1 или более поздней версии. Более старые версии клиента LFS не совместимы с изменениями в аутентификации в этой версии TFS. Чтобы у клиентов было время на переход, мы реализовали краткосрочное обходное решение для RTW. Это решение будет удалено в обновлении 1, и после этого клиенты с версиями LFS Git ниже 1.3.1 больше не будут работать.

Средство восстановления NuGet не обнаруживает пакеты, которые существуют в nuget.org.

  • Проблема.

    При использовании NuGet 3.4.3 или более поздней версии задача восстановления NuGet не будет восстанавливать пакеты из NuGet.org, если явно не указать его в качестве источника в NuGet.Config.

  • Инструкции по решению:

    Убедитесь, что NuGet.org добавлен в NuGet.Config.


Задачи сборки и выпуска NuGet не выполняют проверку подлинности

  • Проблема.

    При использовании Team Foundation Server и системы управления пакетами задачи сборки и выпуска NuGet не проходят аутентификацию при обращении к каналам, если агент запущен от имени пользователя NETWORK SERVICE (это происходит по умолчанию при запуске агента в качестве службы). Это вызвано тем, что в версиях NuGet до 3.5 используются учетные данные, с использованием которых запущен агент сборки, а не учетные данные, предоставленные задачей сборки.

  • Решение

    Для использования задач сборки и выпуска NuGet с каналами TFS с использованием агента, запущенного от имени пользователя NETWORK SERVICE, необходим NuGet 3.5 или более поздней версии.

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

  • Проблема.

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

  • Решение

    Используйте NuGet 3.5 или более поздней версии с агентами сборки TFS.

При обновлении TFS внешние агенты не обновляются автоматически.

  • Проблема.

    Если загрузить расширение из Visual Studio Marketplace, опубликовать его в установке TFS 2015 и затем обновить до TFS 2017, то при публикации новой версии этого расширения в Marketplace оно не будет автоматически обновляться.

  • Инструкции по решению:

    После обновления до TFS 2017 удалите расширения, которые были установлены в TFS 2015. Затем переустановите самые последние расширения. В TFS 2017 мы добавили функцию автоматической проверки на наличие обновленных внешних расширений один раз в день и их обновление.

В определениях выпуска невозможно запустить задачу "Задание в очереди Jenkins".

  • Проблема.

    При запуске задачи "Задание в очереди Jenkins" в определении выпуска клиенты получают ошибку сервера 500.

  • Инструкции по решению:

    Сейчас задачу "Задание в очереди Jenkins" можно запускать в составе определений сборок TFS, но не определений выпусков. Эта возможность будет добавлена в будущем выпуске.

Необходимо перестроить настраиваемые подключаемые модули сервера TFS для библиотек DLL TFS 2017.

  • Проблема.

    Настраиваемые подключаемые модули для сервера TFS не работают после обновления до TFS 2017.

  • Инструкции по решению:

    Перестройте настраиваемые подключаемые модули в соответствии со сборками TFS 2017.

После выхода TFS 2015 RTM серверная объектная модель для настраиваемых подключаемых модулей TFS была изменена.

  • Проблема.

    Невозможно скомпилировать настраиваемые подключаемые модули сервера TFS.

  • Инструкции по решению:

    Исправьте исходный код, как описано в этой записи блога.

При использовании действий администратора создается исключение

  • Проблема.

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

  • Инструкции по решению:

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

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

Проблема при использовании задач для запуска функциональных тестов в Team Build/Release Management

  • Проблема.

    Для запуска функциональных тестов в Team Build и Release Management с помощью задач "Развертывание агента тестирования Visual Studio" и "Запуск функциональных тестов" из каталога задач сейчас используется Agents для Visual Studio 2015 с обновлением 3. Кроме того, эти задачи позволяют запускать только тесты, созданные с использованием Visual Studio 2013 и Visual Studio 2015. Их нельзя использовать для запуска тестов, созданных с помощью Visual Studio 2017 RC. Подробности см. в этой записи блога.

  • Инструкции по решению:

    Способа решения этой проблемы не существует. Поддержка для использования Test Agent 2017 и запуска тестов, созданных с помощью Visual Studio 2017, будет добавлена на этапе выпуска обновления 1 для Team Foundation Server 2017.

Расширения не обновляются автоматически.

  • Проблема.

    Если вы обновляете предыдущую версию TFS до TFS 2017 и работаете с TFS 2017 в подключенном режиме, расширения не обновляются автоматически, как это должно быть.

  • Решение

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

Если возникли проблемы, из-за которых не удается развернуть рабочую среду (Go-Live), обратитесь в службу технической поддержки Майкрософт. Только в рабочее время США (пн-пт, с 6:00 до 18:00 по тихоокеанскому времени), ответ в течение рабочего дня (только на английском языке).

К началу страницы