Заметки о выпуске Team Foundation Server 2017

Статья
03/28/2024

Примечание

Это не последняя версия Team Foundation Server. Вы можете скачать последний выпуск на странице заметок о текущем выпуске для Team Foundation Server 2018 с обновлением 3. Язык этой страницы можно изменить, щелкнув значок глобуса в нижнем колонтитуле страницы и выбрав нужный язык.

Эта статья содержит сведения о Team Foundation Server 2017. Нажмите кнопку, чтобы скачать файлы.

Дополнительные сведения о Team Foundation Server 2017 см. на странице .

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

" Дата выпуска: 28 февраля 2018 г.

В этом обновлении устранены потенциальные уязвимости, связанные с межсайтовыми сценариями (XSS), и другие проблемы безопасности. Дополнительные сведения см. в записи блога. Это полное обновление, так что можно выполнить обновление непосредственно до TFS 2017.0.1.

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

Сводка новых возможностей Team Foundation Server 2017

Поиск кода
Управление пакетами
Усовершенствования Agile
Усовершенствования панелей мониторинга и мини-приложений
Усовершенствования Git
Усовершенствования сборок
Усовершенствования управления выпусками
Усовершенствования тестов
Усовершенствования Marketplace
Улучшения администрирования
Личные маркеры доступа

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

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

Сведения о новых возможностях Team Foundation Server 2017

Поиск кода

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

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

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

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

Поиск кода

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

Канбан трансляции обновлений — *Рис. 5. Обновление канбан-доски в реальном времени*

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

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

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

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

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

Улучшения контрольного списка — *Рис. 6. Гиперссылки контрольного списка*

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

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

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

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

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

Детализация эпических функций — *Рис. 8. Детализация на досках функций и ситуаций*

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

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

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

Включение и отключение примечаний к доске — *Рис. 9. Включение и отключение заметок на доске*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения об этом изменении см. в статье: Синхронизация TFS с Project Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страница измененных ветвей — *Рис. 20. Модернизированная страница ветвей*

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

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

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

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

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

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

*Рис. 21. Заголовок запроса на вытягивание*

Обзор

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

Файлы

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

Обновления

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

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

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

*Рис. 25. Комментарии к запросу на вытягивание*

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

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

*Рис. 26. Добавление рецензентов в запросы на вытягивание*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запрос на вытягивание слиянием Squash — *Рис. 32. Запрос на вытягивание для сжатого слияния*

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

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

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

Возможность трассировки фиксации — *Рис. 33. Прослеживаемость фиксации*

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

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

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

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

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

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

API состояния

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Порядок сборки и столбец — *Рис. 39. Столбец и порядок сборки*

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

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

Сборка по номеру строки — *Рис. 40. От сборки в номер строки*

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

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

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

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

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

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

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

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

На этапе Xamarin.Android теперь поддерживается Mac и Linux.
На этапе Xamarin.iOS теперь поддерживается подписывание и упаковка.
Результаты Xamarin Test Cloud могут отображаться на странице сводки сборки.
Появился новый этап восстановления компонентов Xamarin.
На этапе Установщик NuGet теперь поддерживается Mac OS.

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

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

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

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

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

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

*Рис. 43. Запросы на вытягивание SonarQube*

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

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

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

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

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

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

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

Триггеры ci Git — *Рис. 44. Триггеры CI в Git*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Передача маркеров OAuth в скрипты — *Рис. 47. Передача токенов OAuth в скрипты*

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

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

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

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

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

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

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

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

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

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

Установка параметра для активации после частично успешного выпуска — *Рис. 50. Установка параметра для активации при частично выполненном выпуске*

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

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

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

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

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

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

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

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

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

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

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

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

Группы задач

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

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

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

Связывание кода в репозитории GutHub с определением выпуска с помощью групп задач — *Рис. 53. Связывание кода в репозитории GitHub с определением выпуска*

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

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

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

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

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

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

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

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

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

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

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

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

Сохранить выпуски — *Рис. 55. Хранение выпусков*

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

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

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

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

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

Дополнительные сведения см. в документации [Псевдоним источника артефакта](/vsts/pipelines/release/artifacts?preserve-view=true&view=vsts#source-alias).

Ряд переменных в формате Build.* (например, Build.BuildId и Build.BuildNumber) доступен для использования в параметрах задачи. Если с выпуском связано несколько источников, теперь эти переменные заполняются значениями из источника артефакта, который указан в качестве основного. Дополнительные сведения см. в статье Переменные артефактов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вложения этапов тестирования — *Рис. 78. Вложения для шагов теста*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просмотр рабочего элемента — *Рис. 82. Произвольное тестирование из расширения*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запрос на отзыв

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

Поток обратной связи по запросу XT — *Рис. 87. Процесс предоставления отзыва при произвольном тестировании*

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

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

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

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

XT Предоставление потока обратной связи — *Рис. 89. Процесс предоставления отзыва при произвольном тестировании*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметр задачи — *Рис. 96. Настройка задачи*

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

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

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

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

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

, параметр задачи 1 — *Рис. 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) .

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

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

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

*Рис. 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 и выберите параметр "Включить новую навигацию". Учтите, что в таком случае новая навигация активируется для всех пользователей на сервере.

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

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

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

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

Администратор рабочего концентратора — *Рис. 101. Центр работы для администратора*

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

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

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

Новая возможность для администраторов: поиск с префиксом в домене приложения

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

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

Управляйте личными маркерами доступа и параметрами SSH в новом разделе "Моя безопасность" (рис. 102) . Пользователям, которые управляли открытыми ключами SSH через раздел "Мой профиль", теперь нужно будет переходить для этого к параметрам пользовательской безопасности (рис. 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. Личными маркерами доступа можно управлять на странице параметров безопасности пользователя.

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

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

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

Проблема.

Для TFS 2017 не выпущены Power Tools.
Инструкции по решению:

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

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

Проблема.

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

См. новую документацию: Добавление настраиваемого элемента управления в форму рабочего элемента.

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

Проблема.

Пользователи с установленным расширением страницы рабочего элемента, которые экспортируют определение типа рабочего элемента, а затем импортируют его, увидят сообщение об ошибке: "Атрибут 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.

<packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
</packageSources>

Задачи сборки и выпуска 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 по тихоокеанскому времени), ответ в течение рабочего дня (только на английском языке).

Вы можете ознакомиться с проблемами в Team Foundation Server 2017, о которых сообщали клиенты.

Предложения и отзывы

Мы будем рады узнать ваше мнение! Предложить функцию, сообщить о проблеме и отслеживать ее состояние можно с помощью Сообщества разработчиков, а получить совет можно на сайте Stack Overflow.

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

Заметки о выпуске Team Foundation Server 2017

" Дата выпуска: 28 февраля 2018 г.

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

Сводка новых возможностей Team Foundation Server 2017

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

Сведения о новых возможностях Team Foundation Server 2017

Поиск кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор

Файлы

Обновления

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

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

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

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

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

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

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

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

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

API состояния

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Группы задач

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

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

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

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

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

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

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

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

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

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

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

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