Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Сообщество разработчиков | Требования к системе и совместимость | Условия лицензии | Блог DevOps по TFS | Хэши SHA-1 | | Последние заметки о выпуске Visual Studio 2019|
Примечание.
Это не последняя версия Team Foundation Server. Чтобы скачать последнюю версию, пожалуйста, посетите заметки о текущем выпуске для Team Foundation Server 2018 Update 3. Язык этой страницы можно изменить, щелкнув значок глобуса в нижнем колонтитуле страницы и выбрав нужный язык.
Эта статья содержит сведения о Team Foundation Server 2017. Нажмите кнопку, чтобы скачать файлы.
Дополнительные сведения о Team Foundation Server 2017 см. на странице Требования к Team Foundation Server и совместимость.
Дополнительные сведения см. на странице по установке TFS.
Дата выпуска: 28 февраля 2018 г.
В этом обновлении устранены потенциальные уязвимости, связанные с межсайтовыми сценариями (XSS), и другие проблемы безопасности. Дополнительные сведения см. в записи блога. Это полное обновление, так что можно выполнить обновление непосредственно до TFS 2017.0.1.
Дата выпуска: 16 ноября 2016 г.
Сводка новых возможностей Team Foundation Server 2017
- Поиск кода
- Управление пакетами
- Усовершенствования в Agile
- Усовершенствования панелей мониторинга и мини-приложений
- Усовершенствования Git
- Улучшения сборки
- Усовершенствования управления выпусками
- Усовершенствования тестов
- Усовершенствования рынка
- Улучшения администрирования
- Личные маркеры доступа
Известные проблемы
Сведения о новых возможностях 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).
Когда кто-либо в вашей команде создает, обновляет или удаляет рабочий элемент на доске, вы немедленно получаете обновления на своей доске в реальном времени. Кроме того, если администратор вносит изменения на уровне доски или команды, например, добавляет новый столбец или включает задачи с ошибками в беклог, вам поступит уведомление о необходимости обновить доску для изменения ее макета. Все, что вам теперь нужно сделать, — это включить значок башни на канбан-доске и начать работу с другими членами своей команды.
Дополнительные сведения см. в статье Основы работы с канбан-досками.
Усовершенствования контрольных списков
Мы внесли ряд улучшений в работу контрольных списков.
Элементы контрольных списков теперь отображаются в виде гиперссылок (рис. 6). Можно щелкнуть заголовок, чтобы открыть форму рабочего элемента.
Теперь контрольные списки также поддерживают контекстные меню, позволяющие открывать, изменять или удалять элементы списка (рис. 7).
Дополнительные сведения см. в статье Добавление контрольных списков для задач.
Детализация на досках эпопей и функций
Теперь вы можете подробно изучать доски эпиков и функций (рис. 8). Формат контрольного списка позволяет легко помечать работы как завершенные и дает удобное общее представление о завершенных и незавершенных делах.
Дополнительные сведения см. в статье Функции и эпики Канбан.
Включение и отключение заметок на доске
Мы предлагаем расширенное управление дополнительной информацией, которая отображается на картах ваших досок. Теперь вы можете выбирать заметки, которые хотите видеть на картах канбана (рис. 9). Просто уберите аннотацию, и она исчезнет с карточки на вашей канбан-доске. Первые две заметки, которые отображаются здесь, — это дочерние рабочие элементы (в данном примере задания) и тестовая заметка.
Дополнительные сведения см. в статье Настройка карт.
Команда "Удалить форматирование"
Мы добавили новую команду к элементам управления обычным текстом в рабочих элементах, которая позволяет удалять все форматирование выделенного текста. Если вы как большинство пользователей, возможно, в прошлом пострадали от копирования и вставки форматированного текста в это поле, который невозможно отменить (или очистить). Теперь можно просто выделить нужный текст, нажать на панели инструментов кнопку "Удалить форматирование" (или нажать клавиши CTRL + ПРОБЕЛ), и текст вернется в формат по умолчанию.
Фильтрация на канбан-доске
Настраивайте канбан-доски под себя, используя фильтры для пользователей, итераций, типов рабочих элементов и тегов (рис. 10). Эти фильтры сохраняются, так что вы можете просматривать свою персонализированную доску даже если вы подключаетесь с разных устройств.
Члены команды также могут настроить фильтрацию на своих досках, чтобы увидеть прогресс, связанный с конкретным родительским рабочим элементом. Например, пользователь может просматривать пользовательские истории, связанные с функционалом, или работы по двум или нескольким функционалам, которые укрупняются в эпик. Эта функциональная возможность, как и контрольные списки, введена, чтобы улучшить видимость различных уровней невыполненной работы.
Дополнительные сведения см. в статье Фильтрация на канбан-доске.
Путь итерации по умолчанию для новых рабочих элементов
При создании нового рабочего элемента на вкладке запросов или в мини-приложении панели мониторинга "Создать рабочий элемент" в качестве пути итерации этого рабочего элемента всегда устанавливается текущая итерация. Не всем рабочим группам это подходит, так как это означает, что ошибки могут сразу же отображаться на доске задач. Данное усовершенствование позволяет рабочим группам выбирать путь итерации по умолчанию (какую-либо конкретную или текущую итерацию), который должен использоваться для новых рабочих элементов. Перейдите в область администрирования для вашей группы, чтобы выбрать итерацию по умолчанию.
Дополнительные сведения см. в статье Настройка области и путей итерации.
Элемент управления "флажок"
Теперь в ваши рабочие элементы можно добавлять флажок (рис. 11). Этот новый тип поля (Boolean) имеет все свойства обычных полей, и его можно добавить к любому типу в процессе. При отображении на картах или в результате запроса значение показывается как True или False.
Дополнительные сведения см. в статье Настройка поля.
Массовое редактирование тегов
Теперь вы можете добавлять или удалять теги сразу в нескольких рабочих элементах через диалоговое окно массового редактирования (рис. 12).
Дополнительные сведения см. в статье Добавление тегов к рабочим элементам.
Новые точки расширения
Мы добавили новую точку расширения на страницах доски и невыполненной работы, что позволяет создавать расширения в виде поворотной вкладки рядом с вкладками Доска, Невыполненная работа и Ресурсы.
Мы обнаружили новую точку расширения в бэклоге. Расширения могут быть нацелены на панель справа, где сейчас находятся сведения о сопоставлении и работе (рис. 13).
Усовершенствования электронной почты
Мы значительно улучшили форматирование и удобство оповещений о рабочих элементах, подписок, а также сообщений электронной почты @mention, отправляемых TFS (рис. 14). Сообщения электронной почты теперь включают типовой заголовок, четкий призыв к действию и имеют улучшенное форматирование, чтобы сведения в сообщении электронной почты было проще понимать и использовать. Кроме того, все эти сообщения электронной почты разрабатываются так, чтобы они хорошо отображались на мобильных устройствах.
Дополнительные сведения см. в статье Оповещения рабочих элементов.
Шаблоны рабочих элементов
Мы добавили возможность создавать форматированные шаблоны рабочих элементов непосредственно в веб-интерфейсе (рис. 15). Ранее эта возможность была очень ограничена в вебе и стала доступна в такой новой форме только через расширение Visual Studio. Теперь команды разработчиков могут создавать наборы шаблонов для быстрого изменения стандартных полей и управлять ими.
Дополнительные сведения см. в статье Шаблоны рабочих элементов.
Интеграция с Project Server больше не поддерживается
В Team Foundation Server 2017 и более поздних версиях больше не поддерживается интеграция с Project Server. При обновлении базы данных TFS, для которой настроена интеграция с Project Server, до версии RC2 вы получите следующее предупреждение.
Мы обнаружили, что для этой базы данных настроена интеграция с 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). Новый дизайн был приведен в соответствие со стилем панелей конфигурации мини-приложений и включает улучшенный интерфейс поиска.
Дополнительные сведения см. в статье Каталог мини-приложений.
Обновления виджетов
Мини-приложение "Плитка запроса" теперь поддерживает до 10 условных правил и позволяет выбирать цвета (рис. 17). Это очень удобно, когда нужно использовать эти плитки в качестве ключевых показателей эффективности для определения состояния и/или действий, которые могут понадобиться.
Виджет Pull Request теперь поддерживает несколько размеров, позволяя пользователям контролировать его высоту. Мы собираемся включить возможность изменения размера в большинство поставляемых мини-приложений, так что ищите дополнительную информацию здесь.
Мини-приложение "Создать рабочий элемент" теперь позволяет выбрать тип рабочего элемента по умолчанию, чтобы вам не нужно было постоянно заново выбирать наиболее часто создаваемый тип в раскрывающемся списке.
Теперь мини-приложения для диаграммы WIT можно масштабировать. Таким образом, пользователи могут видеть на панели мониторинга развернутое представление любой диаграммы рабочих элементов независимо от ее исходного размера.
Мы обновили мини-приложение "Члены команды", чтобы было проще добавлять кого-то в вашу команду (рис. 18).
Теперь команды могут настроить размер мини-приложения "Результаты запроса", отображаемого на панели мониторинга, для вывода большего количества результатов.
Мини-приложение "Обзор спринта" было переработано, чтобы командам было легче отслеживать выполнение плана.
Мини-приложение "Назначено мне" позволяет пользователям легко работать с назначенными им заданиями, не покидая панель мониторинга (рис. 19). С помощью этого мини-приложения администраторы команды смогут добавить эту функцию на свои панели мониторинга, сэкономив 16 щелчков мышью; нет переключения контекста или необходимости что-либо вводить. Пользователи смогут просматривать и фильтровать назначенные им задания, а также управлять ими в контексте мини-приложения.
REST API панелей мониторинга
Теперь вы можете использовать интерфейсы REST API, чтобы добавлять, удалять и получать сведения на панели мониторинга программными средствами. Эти интерфейсы API также позволяют добавлять, удалять, обновлять, заменять и получать сведения о мини-приложении или списке мини-приложений на панели мониторинга. Соответствующую документацию см. в онлайн-документации Visual Studio.
Допустимые панели мониторинга
Пользователи, не являющиеся администраторами, теперь смогут создавать панели мониторинга команды и управлять ими. Администраторы команды смогут ограничить права пользователей, не являющихся администраторами, из диспетчера панели мониторинга.
Дополнительные сведения см. в статье Панели мониторинга.
Усовершенствования Git
Для версии Team Foundation Server 2017 был внесен ряд существенных изменений в Git. Эти изменения включают модернизированную страницу ветвей и новый параметр для "сжатого слияния".
Модернизированная страница ветвей
Страница ветвей была полностью переделана. На нем имеется элемент "Мои," который показывает ветви, которые вы создавали, отправляли изменения в или добавляли в избранное (рис. 20). Для каждой ветки показывается статус ее сборок и pull-запросов, а также другие команды, такие как "Удалить". Если в имени ветви присутствует косая черта, например "features/jeremy/fix-bug", то она отображается в виде дерева, поэтому можно удобно просматривать большой список ветвей. Если имя ветви известно, ее можно быстро найти поиском.
Дополнительные сведения о ветвях см. в статье Управление ветвями.
Новый опыт работы с pull request
В этом выпуске существенно обновлен опыт работы с запросами на включение изменений: добавлены несколько эффективных функций сравнения, включая измененную систему комментирования и полностью обновленный пользовательский интерфейс.
Дополнительные сведения см. в статье Проверка кода с помощью Pull Requests.
Переработанный пользовательский интерфейс
При открытии запроса вы сразу же обратите внимание на новый интерфейс (рис. 21). Мы реорганизовали шапку, чтобы она обобщала все критические состояния и действия, делая их доступными из любого представления в интерфейсе.
Обзор
Обзор теперь подчеркивает описание PR и делает оставление отзывов проще, чем когда-либо (рис. 22). Новейшие события и комментарии отображаются сверху, что позволяет рецензентам видеть последние изменения и комментарии впереди и по центру. Отображение политик, рабочих элементов и рецензентов было переработано и стало более подробным, ясным и четким.
Файлы
Самая заметная новая функция в этом выпуске — это возможность просматривать в запросе на включение внесенных изменений предыдущие обновления (рис. 23). В предыдущих предварительных версиях мы добавили функцию, позволяющую правильно отслеживать комментарии, когда пул-реквест обновляется с изменениями. Однако понять, что происходит между обновлениями, не всегда легко. В представлении "Файлы" теперь можно точно видеть изменения при каждой отправке нового кода в пулл-реквест. Это очень удобно, если вы получили отзыв на какой-либо код и хотите увидеть, как изменился именно этот код без учета всех остальных изменений.
Обновления
Новое представление "Обновления" позволяет увидеть, как Pull Request (PR) меняется с течением времени (рис. 24). Если в представлении "Файлы" показывается, как изменялись файлы с течением времени, то в представлении "Обновления" отображаются коммиты, добавленные в каждом обновлении. В случае принудительной отправки в представлении "Обновления" будут по-прежнему отображаться предыдущие обновления в порядке их возникновения.
Комментарии (теперь с разметкой) и эмодзи
Вам доступны все возможности форматирования Markdown во всех обсуждениях, в том числе подсветка синтаксиса в коде, вставка ссылок, изображений и эмодзи (рис. 25). Интерфейс элементов управления для комментирования также был улучшен. Теперь можно одновременно редактировать (и затем сохранить) несколько комментариев.
Добавление и удаление рецензентов в pull-реквестах
Теперь стало проще добавлять и удалять рецензентов в pull-реквестах. Чтобы добавить рецензента или группу в pull request, просто введите их имя в поле поиска в разделе "Рецензенты". Чтобы удалить рецензента, наведите мышь на его плитку в разделе "Рецензенты" и нажмите кнопку со значком "X" (рис. 26).
Улучшенная прослеживаемость сборок и pull-запросов
Прослеживаемость между сборками и pull-запросами была улучшена, что облегчает переход от pull-запроса к сборке и обратно. В представлении сведений о сборке для сборки, инициированной запросом на включение внесенных изменений, в источнике теперь будет отображаться ссылка на запрос на включение внесенных изменений, который поставил эту сборку в очередь. В представлении определений сборок любая сборка, инициированная запросом на включение внесенных изменений, будет содержать ссылку на запрос на включение внесенных изменений в столбце "Triggered By" ("Инициировано"). Наконец, в представлении обозревателя сборок все запросы на включение внесенных изменений будут перечислены в исходном столбце.
Отслеживание комментариев в пул-реквестах
Теперь в запросах на включение изменений в VSTS комментарии отображаются в соответствующей строке файла, даже если файл был изменен после добавления комментариев. Раньше комментарии всегда отображались в той строке файла, куда они были изначально добавлены, даже если содержимое файла изменялось. Другими словами, комментарий в строке 10 всегда отображался в строке 10. В соответствии с последними усовершенствованиями при изменении кода расположение комментария меняется, чтобы не обмануть ожидания пользователя. Если комментарий был добавлен в строке 10, а потом в начало файла были добавлены две новые строки, комментарий будет отображаться в строке 12.
Вот пример изменения с комментарием на строке 13 (рис. 27):
Даже после изменения кода, которое перенесло строку с первоначальным комментарием с 13 на 14, комментарий отображается в ожидаемом месте на строке 14 (рис. 28).
Автоматическое завершение запросов на включение внесенных изменений, ожидающих обработки политиками
Если ваша команда использует политики ветвей для защиты своих ветвей, рекомендуем попробовать действие автозавершения. Часто создатель pull-запроса готов слить свой запрос, но ему приходится ждать окончания сборки, чтобы нажать "Завершить". В других случаях сборка проходит, но один из рецензентов не дал окончательного утверждения. В этих случаях функция автозавершения позволяет автору запроса сделать так, чтобы запрос завершился сам, как только все политики будут утверждены (рис. 29).
Как и при завершении вручную, автор может сам настроить сообщение, которое будет появляться при фиксации слияния, и выбрать нужные параметры слияния (рис. 30).
После настройки автозавершения в запросе на включение внесенных изменений появится баннер, сообщающий о том, что включено автозавершение и оно ожидает готовности политик (рис. 31).
Когда все политики соблюдены (например, при завершении сборки или при получении необходимого окончательного утверждения), для запроса выполняется слияние с указанными параметрами и комментариями слияния. Как и ожидалось, если при сборке проекта возникает сбой или если рецензент не дает утверждения, пулреквест остается открытым, пока правила не будут соблюдены.
Запросы на включение внесенных изменений сжатого слияния
Теперь при завершении pull запроса у вас есть возможность слияния с сжатием (рис. 32). Эта новая опция создает один коммит, содержащий изменения из тематической ветви, которые будут применены к целевой ветви. Самое заметное различие между обычным слиянием и слиянием с сжатием состоит в том, что коммит сжатого слияния имеет только один родительский коммит. Это будет означать более простой хронологический график, так как все промежуточные фиксации, выполненные в тематической ветке, не будут доступны в итоговом графике фиксации.
Дополнительные сведения см. в статье Запросы на включение изменений с использованием Squash merge.
Прослеживаемость коммитов
Состояние сборки (успешное или неудачное) теперь четко видно в видах "Обозреватель кода" и "Сведения о фиксации" (рис. 33). Более подробные сведения находятся всего в одном клике: так вы всегда будете знать, успешно ли изменения в коммите прошли сборку. Вы также можете настроить, какие сборки публикуют статус, в параметрах определения сборки для репозитория. Кроме того, теперь в окне "Сведения о фиксации" предоставляются более глубокие сведения о внесенных изменениях. Если вы используете pull requests для слияния изменений, то увидите ссылку на pull request, который внес изменения в основную ветку (или в случае коммита слияния — на pull request, который его создал). Когда ваши изменения попадут в ветвь main, появится ссылка на эту ветвь для подтверждения того, что изменения были включены.
Просмотр файлов Git LFS в Интернете
Если вы уже работали с большими файлами (аудио, видео, наборами данных и т. д.) в Git, то знаете, что хранилище больших файлов (LFS) Git заменяет эти файлы указателями в Git, сохраняя содержимое файла на удаленном сервере. Это позволяет просматривать все содержимое этих больших файлов, просто щелкнув нужный файл в репозитории.
Дополнительные сведения см. в статье Управление большими файлами с помощью Git.
Создание и отправка ссылок в определенные разделы кода
Вы можете легко делиться сегментами кода с помощью ссылок на код (рис. 34). Просто выделите текст в файле и щелкните значок ссылки. Будет скопирована ссылка на выделенный код. При просмотре кем-либо этой ссылки выделенный вами код будет иметь золотистый фон. Это работает даже при выделении части строки.
API состояния
Состояние сборки (успех или сбой) теперь четко видно в представлениях "Обозреватель кода" и "Сведения о фиксации" (рис. 35). Более подробные сведения можно получить, просто щелкнув мышью, чтобы всегда знать, прошли изменения в коммите сборку или нет. Вы также можете настроить, какие сборки публикуют статус сборки в параметрах репозитория для данного определения сборки.
Значки для типов файлов
В таких представлениях, как проводник, запросы на включение изменений, сведения о фиксации, shelveset, changeset или любое другое представление, где отображается список файлов, будут видны новые значки файлов, соответствующие расширению файла (рис. 36).
Добавление файла сведений при создании репозитория
Теперь при создании репозитория Git пользователи могут добавлять файл сведений (рис. 37). Добавление файла ReadMe в репозиторий не только помогает другим понять назначение кода, но и позволяет вам немедленно клонировать репозиторий.
Усовершенствования сборок
Помимо других изменений в этом выпуске можно назвать увеличенный размер журналов, добавление шаблонов сборок Java и улучшенную поддержку Xamarin.
Обновленная вкладка очереди сборок
Мы обновили дизайн страницы "В очереди". Теперь на ней отображается более длинный список сборок, которые выполняются или находятся в очереди, в более удобном формате (рис. 38).
Подробнее см. в статье Администрирование системы сборки.
Включите расширения результатов сборки, чтобы указать порядок и столбец.
Теперь вы можете указывать столбец, в котором будут отображаться расширения для раздела результатов сборки, а также порядок, в котором расширения будут появляться (рис. 39). Представление результатов имеет два столбца, и все расширения будут в первом столбце по умолчанию. Примечание. Все сторонние расширения будут отображаться после включенных нами разделов результатов сборки.
Привязать к номеру строки
Теперь вы можете переходить от ошибки сборки в строку кода, в которой она возникла. Глядя на последнюю ошибку в основной сборке, которую мы используем внутренне в соответствии с политикой pull request, вы увидите следующее (рис. 40):
Просмотр журналов сборки поддерживает журналы значительно большего размера
Предыдущее представление журналов поддерживало только журналы до 10 000 строк. Новое средство просмотра построено на основе редактора Monaco, используемого в VS Code, и будет поддерживать журналы до 150 000 строк.
Шаблоны сборок Java
Мы упростили для разработчиков Java начало работы со сборкой, добавив шаблоны сборок для Ant, Maven и Gradle (рис. 41).
Дополнительные сведения о шаблонах см. в статье Этапы сборки.
Задачи сборки 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 в запросы на извлечение.
Настройка отчетов API состояния для определения сборки
Теперь вы можете выбирать, какие определения сборок сообщают свое состояние обратно в API состояния Git. Это особенно полезно, если имеется много определений, которые создают конкретный репозиторий или ветвь, но существует только одно, отражающее реальное состояние.
Дополнительные сведения см. в справочном руководстве по REST API.
Поддержка Build vNext в командных комнатах
Пользователи всегда могли добавлять уведомления о сборках XAML в комнате команды. В рамках этого спринта пользователи также могут получать уведомления о завершении процесса в Build vNext.
Включение фильтров пути для триггеров CI в Git
Триггеры CI для размещенных репозиториев Git могут включать или исключать определенные пути. Это позволяет настроить определение сборки таким образом, чтобы сборка выполнялась только при изменении файлов в заданных папках (рис. 44).
Усовершенствования управления выпусками
С появления интегрированной возможности веб-управления выпусками в Team Foundation Server 2015 в нее внесен ряд усовершенствований.
Клонирование, экспорт и импорт определений выпусков
Мы добавили в центр выпусков возможность клонирования, экспорта и импорта определений выпусков без необходимости установки расширения (рис. 45).
Для получения более подробной информации см. документацию Клонирование, экспорт и импорт релиза.
Результаты теста отображаются в сводной информации о выпуске
На странице сводки о выпуске мы включили точку интеграции для внешнего сервиса для отображения информации о конкретной среде.
В Team Services эта функция используется для отображения сводки по результатам тестов при их выполнении в среде выпуска (рис. 46).
Дополнительные сведения см. в статье Общие сведения о представлении сводки для выпуска.
Передача токенов OAuth для скриптов
Чтобы выполнить настраиваемый скрипт PowerShell, который вызывает API REST в Team Services, возможно, для создания рабочего элемента или запроса сведений в сборке в него необходимо передать маркер OAuth.
В настройках среды доступен новый параметр, позволяющий выполнять в среде сценарии как задачи для доступа к текущему маркеру OAuth (рис. 47).
Дополнительные сведения см. в статье Общие параметры среды.
См. простой пример, как получить определение сборки (рис. 48):
Запуск при частично успешных развертываниях
Для каждой задачи сборки и выпуска можно выбрать параметр Продолжить при ошибке в настройках управления.
Если задача с таким параметром завершится сбоем, в определении сборки отобразится результат Сборка выполнена частично.
Теперь такое же поведение доступно в определениях выпуска. При невыполнении задачи отобразится общий результат "Release partially succeeded" (Выпуск выполнен частично) (рис. 49).
По умолчанию частично выполненный выпуск автоматически не запустит выпуск для последующей среды, даже если соответствующий параметр задан в настройках развертывания среды.
Но теперь вам доступен новый параметр для всех сред выпуска, позволяющий сделать так, что Release Management будет запускать выпуск и в последующих средах, даже если выпуск в предыдущей среде выполнен лишь частично (рис. 50).
Дополнительные сведения см. в статье Триггеры среды развертывания.
Потребляйте артефакты, хранящиеся в GitHub, напрямую.
Иногда вам может захотеться напрямую использовать артефакты, которые хранятся в системе управления версиями, без их передачи через процесс сборки, как описано в этой теме.
Теперь то же самое можно выполнить для кода, хранящегося в репозитории GitHub (рис. 51).
Дополнительные сведения см. в статье Источники TFVC, Git и GitHub.
Развертывание веб-приложений с помощью ARM
Доступна новая версия задачи развертывания веб-приложений Azure, которая называется Развертывание веб-приложения AzureRM.
Она использует MSDeploy и подключение к служебной конечной точке Azure Resource Manager. Эта задача предназначена для развертывания веб-заданий Azure и приложений Azure API, а также веб-приложений на основе ASP.NET 4, Node и Python.
Задача также поддерживает общие параметры публикации, такие как возможность хранить данные приложений, переводить приложения в автономный режим и удалять дополнительные файлы в месте назначения.
В будущих версиях могут появиться дополнительные функции, например преобразования конфигураций (рис. 52).
Группы задач
Группа задач позволяет объединить уже заданную в сборке или в определении выпуска последовательность задач в одну задачу для многократного использования. Ее можно будет добавлять в сборку или в определение выпуска так же, как и любую другую задачу (рис. 53).
Можно извлекать параметры из инкапсулированных задач в виде переменных конфигурации и абстрагировать остальные сведения о задаче.
Новая группа задач автоматически добавляется в каталог задач, готовая для добавления в другие выпуски и конфигурации сборки.
Дополнительные сведения см. в статье Группы задач.
Обратимое удаление выпусков
При удалении выпуска или его автоматическом удалении политикой хранения он будет удален из списков обзора и сведений.
Однако прежде чем выпуск будет удален окончательно, он хранится с определением выпуска в течение конкретного периода (обычно 14 дней).
В этот период он отображается на вкладке Удалено в обзорных и детальных списках.
Чтобы восстановить любой из этих выпусков, откройте контекстное меню и выберите Отменить удаление(рис. 54).
Дополнительные сведения см. в статье Восстановление удаленных выпусков.
Сохраняйте выпуски и сборки для каждой среды
Политика хранения для определения выпуска определяет, как долго будет храниться выпуск и связанные с ним сборки.
По умолчанию выпуск хранится 60 дней. Выпуски, которые не были развернуты или изменены в течение этого времени, будут автоматически удалены.
Однако может потребоваться сохранить несколько выпусков, развернутых в определенных средах, например в рабочей среде, или хранить их дольше, чем те, которые только что были развернуты в других средах, таких как среда тестирования, промежуточная среда и среда контроля качества.
Кроме того, связанную с выпуском сборку можно хранить в течение того же периода, что и выпуск. Это обеспечит доступность артефактов в случае, если этот выпуск потребуется развернуть повторно (рис. 55).
Дополнительные сведения см. в статье Хранение выпусков и сборок.
Усовершенствования связанных артефактов
Две новые функции упрощают работу с артефактами и источниками артефактов.
- К определению релиза можно привязать несколько источников артефактов (рис. 56). Каждый из артефактов загружается в папку на агенте, который называется псевдонимом источника. Теперь псевдоним источника связанного артефакта можно редактировать. Например, при изменении имени определения сборки можно отредактировать псевдоним источника в соответствии с именем определения сборки.
- Ряд переменных в формате Build.* (например, Build.BuildId и Build.BuildNumber) доступен для использования в параметрах задачи. Если с выпуском связано несколько источников, теперь эти переменные заполняются данными из указанного вами основного источника артефактов. Дополнительные сведения см. в статье Переменные артефактов.
Развертывание — задача "Ручное вмешательство"
Теперь можно приостанавливать выполнение во время развертывания в среде.
С помощью задачи "Вмешательство вручную" в среде вы можете временно остановить развертывание, выполнить определенные действия вручную, а затем возобновить дальнейшие автоматические действия.
После вмешательства вручную вы также можете отклонить развертывание и запретить выполнение дальнейших действий (рис. 57).
Дополнительные сведения см. в статье Вмешательство вручную.
Сценарии для задачи развертывания базы данных SQL
В задачу Развертывание базы данных SQL Azure(рис. 58) добавлена возможность выполнения SQL-сценариев в базе данных SQL Azure. Сценарии могут иметь вид файла или быть встроенными в задачу.
Сводка описания выпуска - виджет панели мониторинга
Закрепите определение релиза на панели мониторинга — это простой способ сделать сводку релизов для этого определения видимой для всей вашей команды.
Дополнительные сведения см. в документации Добавление информации о выпуске на информационную панель.
Развертывание выпусков в среде в определенное время
Хотите, чтобы все развертывания в продакшене осуществлялись в полночь? Вы можете задать для среды условие, в соответствии с которым будет выбираться успешное развертывание (или просто последнее развертывание) из другой среды, которое будет запускаться в указанное время (рис. 59).
Разверните в зависимости от условий в нескольких средах
До предыдущей версии можно было выполнять параллельные развертывания (параллельные развертывания), однако нельзя было запустить развертывание в среду на основе состояния нескольких сред (совмещенные развертывания). Теперь это возможно.
Дополнительные сведения см. в разделе Параллельные разветвленные и объединенные развертывания.
REST API для управления выпусками
С помощью REST API для службы управления выпусками можно создать определения выпусков и выпуски, а также управлять многими аспектами развертывания выпуска.
Дополнительные сведения см. в справочной документации по API.
Интеграция хуков службы
Настройте отправку уведомлений при создании новых релизов, начале или завершении развертывания, а также при ожидании или завершении утверждений. Интегрируйте сторонние средства, например Slack, для получения таких уведомлений.
Развертывание в национальных облаках Azure
Новый параметр среды в конечной точке классической службы Azure предназначен для конкретного облака Azure, включая предварительно определенные национальные облака Azure, такие как облако Azure в Китае, облако Azure для государственных организаций в США и облако 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). Теперь вы можете создавать конфигурации тестов и переменные конфигураций тестов и управлять ими в центре тестирования.
Дополнительные сведения см. в разделе Create configurations and variables (Создание конфигураций и переменных).
Назначение конфигураций для планов тестирования, наборов тестов и тестовых случаев
Назначение конфигураций стало проще. Вы можете задавать конфигурации для планов тестирования, наборов тестов или тестовых случаев непосредственно в центре тестирования (рис. 62). Щелкните элемент правой кнопкой мыши, выберите Назначить конфигурации для ..., и процесс начнется. Можно также фильтровать по конфигурациям в центре тестирования (рис. 63).
Дополнительные сведения см. в разделе Assign configurations to test plans and suites (Назначение конфигураций планам тестирования и наборам тестов).
Просмотр столбцов плана тестирования и набора тестов в панели результатов тестирования.
Мы добавили в область результатов тестирования новые столбцы, показывающие план тестирования и набор тестов, в котором были получены результаты тестирования. Эти столбцы позволяют увидеть часто необходимый контекст для анализа результатов (рис. 64).
Порядок тестов в центре тестирования и на картах
Теперь вы можете упорядочивать в центре тестирования тесты, выполняемые вручную (рис. 65), вне зависимости от типа наборов, в которые они включены: это могут быть статические наборы либо наборы на основе требований или запросов. Чтобы изменить порядок тестов, можно просто перетащить один или несколько тестов или воспользоваться контекстным меню. После завершения упорядочивания тестов можно сортировать их по полю "Порядок" и затем выполнять в этом порядке через Web Runner. Вы также можете упорядочивать тесты непосредственно в карте пользовательской истории на канбан-доске (рис. 66).
Упорядочивание наборов тестов в центре тестирования
Команды тестирования теперь могут упорядочить наборы тестов в соответствии со своими потребностями. До введения этой возможности наборы программ сортировались только в алфавитном порядке. Теперь, используя возможность перетаскивания в Test hub, можно изменять порядок наборов среди наборов равного уровня или перемещать их в другой набор в иерархии (рис. 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, как описано выше.
Настройка результатов тестов для тестов в разных наборах тестов
Мы добавили возможность настраивать результаты для тестов, используемых в разных наборах в одном плане тестирования (рис. 73). При выборе этого параметра и настройке результата теста (пометить этот тест как "Успешный", "Неудачный" или "Заблокированный" из Центра тестирования, средства Web Runner или из карточек на канбан-доске) этот результат будет распространен на все остальные тесты в разных наборах тестов в составе одного плана тестирования с той же конфигурацией. Пользователи могут установить параметр "Настроить результаты тестов" для конкретного плана тестирования либо из контекстного меню плана тестирования в Центре тестирования, либо на странице тестирования канбан-доски в диалоговом окне общих параметров конфигурации. По умолчанию этот параметр отключен, и его нужно включить явным образом, чтобы изменения вступили в силу.
Проверка ошибок из рабочего элемента
Теперь вы можете проверить ошибку, повторно запустив тесты, в которых она была выявлена (рис. 74). Вы можете вызвать параметр Проверить в контекстном меню формы рабочего элемента ошибки, чтобы запустить соответствующий тестовый случай в среде Web Runner. Выполните проверку с помощью средства Web Runner и обновите рабочий элемент ошибки непосредственно в средстве Web Runner.
REST API для клонирования плана тестирования или набора тестов
Мы добавили интерфейсы REST API для клонирования планов тестирования и наборов тестов. Вы можете найти их в разделе управления тестированием на нашем сайте интеграции Team Services.
Ход выполнения теста на канбан-картах
Теперь вы можете добавлять тестовые случаи, просматривать их и взаимодействовать с ними непосредственно из историй на канбан-доске. Создайте связанный тестовый случай, используя новый пункт меню Добавить тест, и затем отслеживайте состояние непосредственно из карточки по мере выполнения (рис. 75).
Благодаря этой новой возможности вы можете выполнять следующие действия непосредственно из карты на доске.
- Добавьте тесты.
- Открывать тесты.
- Перенесите тест, перетаскивая его из одной пользовательской истории в другую.
- Копировать тест в другую пользовательскую историю, используя клавишу CTRL и перетаскивание (для сценариев, где один тест используется для тестирования нескольких пользовательских историй).
- Обновлять состояние теста, быстро помечая его как Пройдено/Не пройдено/и т. д.
- Выполнять тест, запустив его в средстве выполнения тестов Web Test Runner, в котором можно помечать отдельные шаги как пройденные или неудачные, регистрировать ошибки и т. д.
- Просмотр сводного статуса, показывающего, сколько тестов было пройдено и сколько осталось для этой истории.
Если требуются расширенные возможности управления тестами (такие как назначение тест-инженеров, назначение конфигураций, централизованные параметры, экспорт результатов тестов и т. д.), вы можете переключиться в центр тестирования и начать использовать наборы по умолчанию на основе планов тестирования или требований, которые создаются для вас автоматически. Дополнительные сведения см. в статье Добавление, выполнение и обновление встроенных тестов.
Переход к набору тестов и плану тестирования из карты
Теперь можно с легкостью перейти к базовому плану тестирования и набору тестов, на базе которых созданы тесты, непосредственно из карточки на канбан-доске. Щелкните ссылку (рис. 76), чтобы перейти в центр тестирования, где можно открыть подходящий план тестирования и выбрать определенный набор для управления этими встроенными тестами.
Тестовая страница в конфигурации общих настроек канбан-доски
Новая страница "Тесты" в диалоговом окне общих параметров на канбан-доске позволяет управлять планом тестирования, в рамках которого создаются встроенные тесты (рис. 77). Ранее все тесты, созданные на карте, автоматически добавлялись в создаваемый план тестирования, если не существовало тестовых планов, соответствующих областям и путям итераций карты. Теперь это поведение можно переопределить. Для этого нужно настроить любой имеющийся план тестирования, и все тесты будут добавляться в выбранный план. Обратите внимание, что эта функциональность включена только в том случае, если аннотация теста активирована.
Улучшения средства Web Runner
Добавление вложений для шагов теста во время тестирования вручную
Мы усовершенствовали веб-средство выполнения тестов: теперь оно позволяет вам добавлять вложения для шагов теста при тестировании вручную (рис. 78). Эти вложения для результатов этапов автоматически отображаются во всех ошибках, зарегистрированных во время сеанса, а затем в области результатов тестирования.
Скриншоты, запись экрана, журнал активности с изображениями и информация о системе в веб-интерфейсе (с использованием браузера Chrome)
Теперь в веб-исполнителе можно делать снимки экрана и сразу аннотировать их, когда вы используете Chrome (рис. 79). Кроме того, можно создавать видеозаписи экрана по запросу не только для веб-приложений, но и для классических приложений. Эти снимки экрана и видеозаписи экрана автоматически добавляются в текущий шаг теста. Помимо создания снимков экрана и видеозаписей действий на экране можно настроить ведение журнала действий с изображениями по требованию из веб-приложений. Нужно указать окно обозревателя для записи действий. Все действия в этом окне (на имеющихся или новых открытых вкладках) или в любых новых запущенных дочерних окнах браузера будут автоматически записываться и сопоставляться с шагами теста, выполняемого в Web Runner. Затем эти снимки экрана, видеозаписи экрана и журналы действий с изображениями добавляются к записям об ошибках, зарегистрированным во время выполнения, а также присоединяются к результатам текущего теста. Аналогично, сведения о системе автоматически записываются и включаются в каждую ошибку, зарегистрированную из Web Runner. При этом задействуется возможность из расширения "Тестирование и обратная связь" на основе браузера Chrome.
Дополнительные сведения см. в разделе Collect diagnostic data during tests (Сбор диагностических данных во время выполнения тестов).
Ошибки, оформленные как дочерние элементы, — веб-исполнитель и расширение "Тестирование и обратная связь"
При выполнении в Web Runner тестов, запущенных из карты на доске или из набора на основе требований в центре тестирования, все новые зарегистрированные ошибки теперь будут автоматически создаваться как дочерние для данной пользовательской истории. Аналогично, если вы исследуете пользовательскую историю из расширения исследовательского тестирования, зарегистрированные вами новые ошибки также будут создаваться как дочерние для данной пользовательской истории. Это новое поведение упрощает прослеживаемость историй и ошибок. Это применимо только в том случае, если для параметров "Работа с ошибками" на странице "Конфигурация общих параметров" задано значение "Ошибки не отображаются в невыполненных работах и на досках" или "Ошибки отображаются в невыполненных работах и на досках с задачами". Для всех остальных настроек параметра "Работа с ошибками" и некоторых сценариев, таких как добавление в существующую ошибку, уже имеющую заданного родителя, вместо этого будет создана связанная ссылка.
Обновление существующих ошибок в веб-исполнителе
В дополнение к созданию новых ошибок с помощью веб-исполнителя, теперь вы также можете обновлять уже существующие ошибки (рис. 80). В существующую ошибку автоматически добавляются все данные диагностики, шаги воспроизведения и ссылки для отслеживания, собранные в текущем сеансе.
Расширение тестирования и обратной связи — улучшения
Расширение "Тестирование и обратная связь" на основе браузера можно установить из Visual Studio Marketplace. Оно поддерживает Visual Studio Team Services и Team Foundation Server (2015 или более поздней версии).
Исследуйте рабочие элементы
Теперь вы можете выполнять произвольное тестирование для определенных рабочих элементов (рис. 81). Это позволяет связать выбранный рабочий элемент с выполняющимся сеансом тестирования, а также просматривать условия приемки и описание прямо в расширении. Кроме того, вы можете отслеживать все ошибки и задачи, зарегистрированные для выбранного рабочего элемента, равно как и взаимосвязи между ними. Изучать рабочий элемент можно непосредственно из него самого либо из расширения:
• Непосредственно из рабочего элемента (рис. 81): выберите "Выполнить произвольное тестирование" в контекстном меню, чтобы запустить сеанс произвольного тестирования для конкретного рабочего элемента непосредственно из продукта. Мы добавили точки входа на все карты, таблицы и в центр тестирования.
• В расширении (рис. 82): выполните поиск рабочего элемента в сеансе XT и свяжите его с текущим сеансом.
Дополнительные сведения см. в статье Explore work items with the Test & Feedback extension (Изучение рабочих элементов с помощью расширения "Тестирование и обратная связь").
Расширение "Тестирование и обратная связь": фиксация действий с изображениями, запись экрана и данных загрузки веб-страниц
Журнал действий с изображениями: расширение предоставляет новую возможность автоматически добавлять последовательность действий, которые приводят к ошибке, всего одним щелчком мыши. Выберите параметр "Включить журнал действий с изображениями" (рис. 83), чтобы записывать действия, выполняемые с клавиатуры, мыши или сенсорного экрана. Вы сможете добавлять соответствующий текст и изображения непосредственно в ошибки или задачи.
Видеозапись экрана. С помощью этого расширения вы можете создавать видеозаписи действий на экране по запросу. Эти видеозаписи экрана можно создавать не только для веб-приложений, но и для настольных приложений. Расширение можно настроить для автоматической остановки видеозаписей экрана и их присоединения к записываемой ошибке с помощью страницы расширения "Параметры".
Данные о загрузке страницы. Мы добавили новую возможность записи фоновых данных в расширение — запись данных о загрузке веб-страницы. Точно так же, как журнал действий с изображениями сохраняет в фоновом режиме ваши действия, выполненные в исследуемом веб-приложении в виде изображений на заднем плане, функция загрузки страницы автоматически фиксирует детали при загрузке веб-страницы для завершения операции. Вместо того чтобы полагаться на субъективное или воспринимаемое замедление загрузки веб-страницы, теперь можно объективно quantificировать это замедление в баге. После регистрации ошибки помимо мозаичного представления к ошибке также прикрепляется подробный отчет, который может помочь разработчику в начале исследования.
Создание тестовых случаев на основе данных журнала действий с изображениями
Теперь вы можете создавать тестовые случаи во время сеанса произвольного тестирования. При этом шаги теста с изображениями заполняются автоматически (рис. 84). Одновременное проектирование теста и его выполнение — это основа для настоящего произвольного тестирования, и эта новая возможность делает это реальным. Вы можете изменять записанный текст, добавлять ожидаемый результат, снимать флажки с неподходящих строк и сохранять его для будущего прохождения или выполнения тестов.
Для получения дополнительной информации см. Создание тестовых случаев на основе данных журнала действий с изображениями.
Взгляды на сеанс исследовательского тестирования
Теперь вы можете просматривать завершенные сеансы произвольного тестирования, созданные с помощью расширения "Тестирование и обратная связь", на индивидуальном уровне или уровне группы, в течение заданного периода времени. На эту страницу выводов можно перейти, щелкнув ссылку "Последние сеансы разведочного тестирования" в центре запусков в группе центра тестирования в веб-доступе. Это новое представление помогает получать важные аналитические сведения, включая следующее.
- Сводное представление с информацией об исследуемых рабочих элементах, созданных рабочих элементах и владельцах сеансов, а также общее время, затраченное на эти сеансы (рис. 85).
- Представление с разбивкой, которое можно сводить по исследуемым рабочим элементам, сеансам, владельцам сеансов или не используя ни один из этих параметров. Для любого параметра можно либо просмотреть список всех созданных рабочих элементов (ошибок, задач, тестовых случаев), либо отфильтровать список по рабочему элементу конкретного типа.
- Представление области сведений, отображающее информацию на основе выбора в представлении с разбивкой. Для выбранной строки сводки (например, для исследуемых рабочих элементов) можно в области сведений просматривать ее сводные данные, такие как общее число сеансов, общее время, затраченное на эти сеансы, владельцы сеансов, выполнявшие исследование, а также ошибки, задачи и тестовые случаи, созданные для них, вместе с их состоянием и приоритетом. Для строки выбранного рабочего элемента можно просмотреть его встроенную форму рабочего элемента и внести соответствующие изменения.
Дополнительные сведения см. в статье Get insights across your exploratory testing sessions (Получение аналитических данных из сеансов произвольного тестирования).
Сеансы произвольного тестирования: просмотр неисследованных рабочих элементов
Помимо возможности видеть все детали исследуемых рабочих элементов в представлении "Недавние сеансы исследовательского тестирования", где можно отфильтровать по всем или только вашим сеансам за заданный диапазон дат, мы теперь добавили возможность видеть список всех рабочих элементов, которые НЕ были исследованы в том же представлении (рис. 86). Сначала нужно настроить общий запрос необходимых рабочих элементов, после чего на странице сеансов отобразится список всех запрошенных рабочих элементов с разбиением по исследованным и неисследованным элементам в разделе сводки. Кроме того, с помощью сводки с группированием по неисследованным рабочим элементам можно просмотреть список элементов, которые еще не были рассмотрены. Это чрезвычайно полезно, чтобы отслеживать, сколько историй еще не было изучено или они еще не прошли тестирование на наличие ошибок.
Комплексный процесс получения отзывов заинтересованных лиц
Запрос отзыва
Пользователи с базовым уровнем доступа теперь могут напрямую запрашивать у заинтересованных лиц отзывы, касающиеся рабочих функций и актуальных или уже завершенных примеров использования. Для этого используется команда "Запрос на отзыв" в меню рабочего элемента (рис. 87). В форме "Запрос на отзыв", которая открывается, вы можете выбрать заинтересованных сторон, от которых хотите получить отзывы, и при необходимости предоставить простой набор инструкций с предложениями по областям продукта, о которых вы хотите получить обратную связь. Это отправит индивидуальные сообщения выбранным заинтересованным сторонам вместе с предоставленными инструкциями, если они есть.
Дополнительные сведения см. в разделе
Предоставление отзыва
Заинтересованные лица могут ответить на запрос на отзыв, щелкнув ссылку "Предоставить отзыв" в полученном сообщении электронной почты, которая автоматически настроит расширение "Тестирование и обратная связь" (прежнее название — расширение "Произвольное тестирование") с выбранным запросом на отзыв (будет предложено установить расширение, если это еще не сделано). Затем заинтересованные лица могут использовать все возможности записи для регистрации мнений и отправить отзывы в виде ответа, описания ошибки или рабочих элементов задачи. Кроме того, они могут перейти на страницу "Запросы отзывов", чтобы в одном месте просмотреть все полученные ими запросы на отзывы. Они могут выбирать в списке запрос, по которому нужно предоставить отзыв, контролировать ожидающие отзыва запросы (рис. 88), отклоняя их или помечая как завершенные, а также выбирать между разными типами запросов, используя переключатель (рис. 89).
Дополнительные сведения см. в
Добровольный отзыв
Помимо упомянутого выше процесса запроса на отзыв, заинтересованные лица могут также использовать расширение для предоставления добровольного отзыва (рис. 90). Нужно открыть расширение, на странице параметров подключения выбрать режим "Подключено" и подключиться к учетной записи и проекту или группе, которым необходимо отправить отзыв. Затем заинтересованные лица с помощью расширения могут записать свои мнения и отправить отзывы в виде ответа, описания ошибки или рабочих элементов задачи.
Дополнительные сведения см. в разделе Provide voluntary feedback (Предоставление добровольного отзыва).
Улучшение автоматического тестирования
Журналы работы консоли и продолжительность тестирования на вкладке тестов в сводке по созданию и выпуску
Журналы консоли результатов теста, которые сохраняются в формате TRX-файлов, извлекаются и публикуются в виде вложений к результатам тестирования (рис. 91). Их можно просматривать на вкладке "Тесты". Загружать TRX-файлы больше не требуется.
Виджет тенденций тестирования для сборок
Мы добавили в коллекцию мини-приложений новое мини-приложение "Тенденция в результатах тестирования" (рис. 92). Используйте это мини-приложение, чтобы добавить на панель мониторинга диаграмму тенденции в результатах тестирования вплоть до последних 30 сборок для определения сборки. Параметры конфигурации мини-приложения помогают настроить диаграмму, чтобы включить такие сводки, как число пройденных тестов, число неудачных тестов, общее число тестов, процент выполненных тестов и длительность тестирования.
Статус тестов в сводке по среде релиза
Для развертывания приложений и выполнения для них тестов рекомендуется использовать среды выпуска. В этом релизе мы интегрировали показатель прохождения тестов для сред выпуска в разделе "Среды" на странице сводки релиза (рис. 93). Как показано на снимке экрана, если при создании среды произошел сбой, вы можете быстро определить, связано ли это с непройденными тестами, просмотрев столбец тестов. Чтобы изучить непройденные тесты для этой среды, щелкните на уровень прохода, чтобы перейти на вкладку "Тесты".
Автоматизированный журнал тестирования для веток и сред выпуска
Отдельные тесты часто выполняются в нескольких ветвях, средах и конфигурациях. Если такой тест завершается сбоем, важно определить, связан ли он только с ветвями разработки, такими как главная ветвь, или же сбои также влияют на ветви выпуска, развертываемые в рабочих средах. Теперь вы можете визуализировать историю теста в различных ветвях, которые он тестирует, открыв вкладку "История" на странице сводки результатов (рис. 94). Аналогичным образом можно выбрать сводку по среде, чтобы визуализировать журнал тестов по различным тестируемым средам выпуска.
Отслеживаемость с непрерывным тестированием
Теперь пользователи могут отслеживать выполнение их требований прямо на панели мониторинга (рис. 95). Мы уже внедрили решение для обеспечения качества требований для пользователей запланированного тестирования, а теперь представляем это нашим пользователям, занимающимся непрерывным тестированием. Пользователи могут напрямую связать автоматические тесты с требованиями, а затем использовать виджеты панели мониторинга, чтобы отслеживать качество требований, которые им интересно отслеживать, используя данные о качестве из сборки или выпуска.
Удаленное тестирование — распределение тестов в зависимости от количества компьютеров
Мы добавили возможность распределения тестов из сборки по удаленным компьютерам с помощью задачи "Запуск функциональных тестов" (рис. 96). В TFS 2015 тесты можно было распространять только на уровне сборки. Эту новую возможность можно активировать с помощью флажка в задаче, как показано ниже.
Автоматическое тестирование для SCVMM и VMware
Пользователи могут динамически настраивать тестовые компьютеры в облаке с помощью Azure или локально с помощью SCVMM или VMware и использовать эти компьютеры для распределенного запуска тестов. Пользователи могут подготовить компьютеры с помощью задач Azure, SCVMM или VMware, а затем выполнить тестирование с помощью задачи "Запуск функциональных тестов".
Анализ SonarQube в задачах Maven и Gradle
Теперь вы можете запускать анализ SonarQube в задачах сборки Maven и Gradle. Для этого установите флажок "Запустить анализ SonarQube" и укажите конечную точку, название проекта SonarQube, ключ и версию проекта (рис. 97).
Вы также получите ссылку на проект SonarQube (рис. 98). Вы можете запросить полный анализ, чтобы увидеть детали о порогах качества, и решить прервать сборку, если они не соответствуют требованиям.
Дополнительные сведения см. в статье The Gradle build task now supports SonarQube analysis (Задача сборки Gradle теперь поддерживает анализ SonarQube).
Усовершенствования рынка
Теперь администраторы коллекции проектов могут перейти к Visual Studio Marketplace из Team Foundation Server и установить бесплатные расширения в коллекции командных проектов. Эти расширения автоматически скачиваются из Visual Studio Marketplace, отправляются в Team Foundation Server и устанавливаются в выбранной коллекции командных проектов (рис. 99).
Приобретение и установка платных расширений
Теперь администраторы коллекции проектов могут перейти из Team Foundation Server в магазин Visual Studio Marketplace, приобрести в нем платные расширения и установить их в выбранной коллекции командных проектов (рис. 100). Администратор может оплатить расширения с помощью подписки Azure и выбрать пользователей, которым будут назначены эти расширения. Расширения автоматически скачиваются из Visual Studio Marketplace, отправляются на Team Foundation Server и устанавливаются в выбранной коллекции командных проектов.
Дополнительные сведения см.в статье Получение расширений для Team Foundation Server.
Улучшения администрирования
Проверка подлинности Windows
В предыдущих выпусках при настройке развертывания TFS, присоединенного к домену, пользователям приходилось выбирать между поставщиками поддержки безопасности — NTLM и Negotiate — для проверки подлинности Windows. В 2017 году мы удалили этот параметр из процесса конфигурации. Чтобы продолжить использование проверки подлинности NTLM в 2017 году, не требуется выполнять никаких действий. Если вы использовали проверку подлинности Kerberos и хотите продолжать в 2017 году, ничего делать не нужно. Теперь TFS 2017 всегда настраивает поставщиков поддержки безопасности Negotiate и NTLM в указанном порядке. В такой конфигурации проверка подлинности Kerberos будет использоваться там, где это возможно, обеспечивая повышенную безопасность. Если нельзя использовать Kerberos, будет использоваться проверка подлинности NTLM. Мы провели обширное тестирование, чтобы гарантировать, что данное изменение не окажет негативное влияние на существующие развертывания TFS, использующие аутентификацию NTLM.
Передовые возможности навигации
В этом выпуске добавлена новая, улучшенная верхняя панель навигации. Существуют две основные цели для новой навигации:
- повысить эффективность навигации по областям продукта, позволяя получить доступ к любому центру одним щелчком;
- добавить современные элементы в графический пользовательский интерфейс и повысить удобство продукта.
Поскольку это значительное изменение для наших пользователей, и функция все еще дорабатывается, новый интерфейс навигации будет отключен по умолчанию. Если вы хотите опробовать их, перейдите на панель управления в области администрирования Team Foundation Server и выберите параметр "Включить новую навигацию". Учтите, что это включается для всех пользователей на сервере.
Права на переименование командного проекта
Разрешение, определяющее, какие пользователи могут переименовывать командный проект, было изменено. Ранее командный проект могли переименовывать пользователи с разрешением "Изменение сведений на уровне проекта" для этого командного проекта. Теперь предоставление или отмена возможности переименования командного проекта пользователями выполняется с помощью нового разрешения "Переименование командного проекта".
Центр работы в параметрах администрирования
Мы ввели новый концентратор "Work" на странице параметров администратора, которая объединяет общие параметры (рис. 101),итерации и области на одной вкладке. При этом изменении пользователи увидят четкие различия между параметрами уровня проекта и параметрами команды. Для параметров группы пользователи будут видеть только области и итерации, относящиеся к их группе. На уровне проекта страница параметров будет позволять администраторам управлять областями и итерациями для всего проекта. Кроме того, для путей к областям проекта был добавлен новый столбец с именем "Группы", чтобы администраторы могли быстро и просто определить, какие группы выбрали конкретный путь к области.
REST API настройки процессов
Этот общедоступный API позволяет пользователям получать конфигурацию конкретного проекта. Конфигурация процесса содержит следующие параметры.
- TypeFields: абстракции настраиваемых полей, используемых в инструментах для гибкой разработки. Например, тип поля "Баллы истории" — "Effort" ("Трудозатраты").
- Определения невыполненной работы: определение, какие рабочие элементы имеются в каждой из невыполненных работ. Это часто запрашиваемый API от клиентов, создающих расширения. С помощью этих данных расширение может узнать, как использовать относящиеся к процессу поля для включения распространенных сценариев в гибких средствах (таких как изменение действия или трудозатраты рабочего элемента, выяснение, какие рабочие элементы включены на заданном уровне невыполненной работы, или определение, идентифицируются ли группы по пути к области или по настраиваемому полю). Пожалуйста, ознакомьтесь с Обзором работы для получения дополнительной информации.
Новый административный интерфейс с поиском по Active Directory с использованием префикса
В выпуске 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, но и с помощью личных маркеров доступа. Это удобно, если вы используете платформу Linux или Mac и хотите использовать средства автоматизации и GIT. Личными маркерами доступа можно управлять на странице параметров безопасности пользователя.
Известные проблемы
Ниже приведен полный список известных проблем в этом выпуске.
Отсутствие средств 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.
<packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
</источникиПакетов>
Задачи сборки и выпуска 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.