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

Сообщество разработчиков | Требования к системе и совместимость | Условия лицензии | Блог по TFS DevOps | Хэши SHA-1 | Заметки о выпуске последней версии Visual Studio 2019

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

Дополнительные сведения о Team Foundation Server 2018 см. на странице Требования к Team Foundation Server и совместимость. Вы можете скачать другие продукты TFS 2018 на странице visualstudio.com/downloads.

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

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

Сводка новых возможностей в TFS 2018

Мы добавили в Team Foundation Server 2018 много новых и полезных функций. Вот некоторые из них:

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

Видео о новинках в TFS 2018

Сборка XAML

Изначально Сборка XAML была отмечена как удаленная из TFS 2018 RTW и обновления 1. Однако из-за этого очень многим клиентам не удалось обновить ее или пришлось обращаться в службу поддержки, чтобы повторно включить ее после обновления. В TFS 2018 с обновлением 2 сборка XAML включена, но использовать ее не рекомендуется. Это значит, что мы больше не занимаемся разработкой сборки XAML, и Microsoft Test Manager (MTM) больше не поддерживает сборки XAML. Рекомендуется перейти на новые форматы определений сборок. Вы можете по-прежнему подключаться к контроллерам XAML и запускать сборки XAML в TFS 2018 с обновлением 2. Дополнительные сведения

Компоненты, удаленные в TFS 2018 RTW

• прекращена поддержка центра лабораторий и потоков автоматического тестирования в Microsoft Test Manager;
• отключено расширение TFS для SharePoint;
• удален компонент Комната команды.

Подробные сведения о новых возможностях в TFS 2018

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

Мастер создания проектов в Интернете

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

Диспетчер шаблонов процессов в Интернете

В TFS 2018 для отправки шаблонов процессов можно использовать веб-интерфейс. Работать с веб-интерфейсом гораздо проще, так как нет необходимости устанавливать соответствующую версию Visual Studio для взаимодействия с вашими шаблонами процессов. В обновлении 4 для Visual Studio 2017 и более ранних версиях по-прежнему отображается диалоговое окно диспетчера шаблонов процессов, хотя мы рекомендуем использовать веб-интерфейс. В обновлении 5 для Visual Studio 2017 и более поздних версиях перенаправление на веб-интерфейс выполняется автоматически.

Настройка заголовка формы рабочего элемента

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

Форма рабочего элемента для мобильных устройств

У нас есть полноценный процесс, в котором оптимизирован интерфейс рабочих элементов (рис. 1). Он позволяет легко работать с элементами, которые были вам назначены, которые вы отслеживаете или просматривали либо недавно изменяли, на телефоне.

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

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

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

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

Развернуть, чтобы показать пустые поля на карточке канбана

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

Щелкните шеврон, направленный вниз, в нижней части карты, чтобы изменить поле (рис. 6).

Расширения, блокирующие сохранение рабочего элемента

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

Встроенная надстройка в планы доставки

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

Управление версиями

Вилки

В TFS 2018 добавлена поддержка форков Git (рис. 8). Форк — это копия репозитория на стороне сервера. Используя форки, вы можете разрешить широкому кругу пользователей вносить вклад в ваш репозиторий, не предоставляя им прямой доступ к коммиту. Вместо этого они фиксируют свою работу в собственном форке репозитория. Это дает вам возможность проверять их изменения в запросе на включение внесенных изменений до принятия этих изменений в центральном репозитории.

GVFS

Теперь поддерживается виртуальная файловая система Git (GVFS). GVFS позволяет масштабировать репозитории Git до миллионов файлов благодаря виртуализации и оптимизации работы Git в файловой системе.

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

Теперь вы можете создавать папки в репозиториях Git и TFVC через Интернет (рис. 9). Эта функция пришла на смену расширению для управления папками, которое будет выводиться из использования.

Чтобы создать папку, нажмите Создать > Папка в панели команд или в контекстном меню:

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

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

Мини-карта файла

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

Сопоставление скобок

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

Включение и отключение отображения пробелов

При просмотре или редактировании файла теперь можно включать и отключать отображение пробелов. В настоящее время мы разрабатываем функцию, которая позволит вам включать и отключать пробелы при сравнении. Чтобы увидеть пробелы (рис. 13), откройте Палитру команд (F1 или щелчок правой кнопкой мыши) и выберите команду Переключение видимости пробелов, которая позволяет различать знаки пробела и табуляции.

Параметр для отключения веб-редактирования репозиториев TFVC

Команды, которые работают с TFVC, часто используют политики регистрации изменений в Visual Studio, чтобы гарантировать высокое качество кода. Тем не менее, так как политики регистрации применяются на стороне клиента, к коду, который изменяется через веб, эти политики не применяются.

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

Чтобы запретить веб-редактирование, со страницы Файлы перейдите на страницу Параметры, а затем — Управление версиями(рис. 14). Нажмите на репозиторий TFVC в дереве, перейдите на вкладку "Параметры" и снимите флажок Включить веб-редактирование для этого репозитория TFVC. По умолчанию веб-редактирование включено.

При попытке веб-редактирования проекта, для которого веб-редактирование отключено, вы получите уведомление о том, что эта операция недопустима (рис. 15).

Определение устаревших ветвей

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

Поиск удаленной ветви и ее повторное создание

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

Для поиска удаленных ветвей введите полное имя ветви в поле поиска ветви. Поиск вернет все существующие ветви, соответствующие этому тексту. Кроме того, можно выполнить поиск точного совпадения в списке удаленных ветвей. Щелкните ссылку, чтобы найти удаленные ветви (рис. 17).

Если соответствие найдено, вы увидите, кто и когда удалил эту ветвь. Вы также можете восстановить ветвь (рис. 18).

При восстановлении ветви выполняется ее повторное создание в той фиксации, на которую она указывала последней. Однако политики и разрешения не будут восстановлены.

Поиск коммита в ветках, начинающихся с префикса

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

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

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

Фильтрация представления в виде дерева в коде

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

Найти фильтр по файлу или папке в дереве фиксаций (рис. 21) и (рис. 22).

Страница "Обновления ветви" заменена страницей "Push-уведомления"

Страница Обновления филиала имеет огромную ценность. Тем не менее, оно было скрыто как ключевой элемент в разделе истории. Теперь страница обновлений ветви отображается как хаб Загрузки(рис. 23) в разделе Код, наряду с Фиксации, Ветки, Теги и Пулл-реквесты. Новый URL-адрес для страницы push-уведомлений: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Старые URL-адреса будут по-прежнему работать.

В то же время центр История переименован в Фиксации(рис. 24), так как теперь в этом разделе отображаются только фиксации. Мы получили отзывы о том, что диагностика неполадок, связанных с фиксациями, представляла трудности, так как в представлении списка фиксаций подробные сведения о времени отображались только по наведению указателя мыши. Теперь в представлении списка фиксаций во всем экземпляре дата и время будут отображаться в формате дд.мм.гг чч:мм. Новый URL-адрес для страницы фиксаций: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Старые URL-адреса будут по-прежнему работать.

Сохранение имени файла при переходе из раздела "Файлы" на страницу "Фиксации"

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

Просмотр тегов Git

Вы можете просмотреть все теги в репозитории на странице Теги(рис. 25). Если вы управляете всеми тегами как выпусками, пользователь может посетить страницу тегов, чтобы просмотреть обобщенное представление всех выпусков продукта.

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

Удаление тегов Git

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

Фильтрация тегов Git

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

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

Безопасность тегов Git

Теперь вы можете точно настраивать разрешения на управление тегами для пользователей репозитория. Используя этот интерфейс, вы можете предоставить пользователям разрешение на удаление тегов или управление тегами (рис. 28).

Автоматическое завершение рабочих элементов при завершении пулл-реквестов

Стало проще поддерживать актуальное состояние всех элементов при связывании рабочих элементов с запросами на вытягивание. Теперь, когда вы завершаете запрос на вытягивание (PR), у вас есть возможность автоматически завершить связанные рабочие элементы после успешного слияния PR (рис. 29). Если вы используете политики и настроили автозавершение запросов на вытягивание, вам также доступна эта функция. Теперь не нужно помнить о возвращении к рабочим элементам, чтобы изменить их состояние после завершения pull request'а. Это делается для вас автоматически.

Сброс голосов при пуше или новой итерации

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

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

Фильтрация дерева pull-запросов по имени файла

Найти конкретный файл в запросе на изменения теперь стало гораздо проще. Новое поле фильтра в представлении Файлы позволяет пользователям фильтровать список файлов в представлении в виде дерева (рис. 32).

Фильтр соответствует любой части пути к файлам в запросе на вытягивание, позволяя вам искать по именам папок, частичным путям, именам файлов или расширениям (рис. 33).

Больше параметров фильтрации комментариев к pull request

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

Просмотреть оригинальные различия для комментариев к коду в деталях pull request.

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

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

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

Проверка кода — это критически важная часть работы с pull request, поэтому мы добавили новые функции, которые помогают рецензентам сосредоточиться на коде. Рецензенты кода могут легко скрывать комментарии, чтобы они не мешали при просмотре кода в первый раз (рис. 37).

Функция скрытия комментариев (рис. 38) скрывает их из представления в виде дерева и сворачивает цепочки комментариев в представлении файлов:

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

Списки задач в описаниях и комментариях к pull request

При подготовке запроса на включение внесенных изменений или создании комментариев у вас, как правило, есть короткий список аспектов, которые требуется отслеживать, но в конце концов приходится редактировать текст или добавлять несколько комментариев. Легкие списки задач — это отличный способ отслеживать прогресс в списке дел как создателю или рецензенту PR в описании или в одном, объединенном комментарии. Щелкните панель инструментов Markdown, чтобы приступить к работе или применить формат к выделенному тексту (рис. 40).

После добавления списка задач (рис. 41) вы можете помечать элементы как завершенные, просто устанавливая флажки. Они выражаются и хранятся в комментарии как [ ] и [x] в файле Markdown. Дополнительные сведения см. в статье Markdown guidance (Руководство по Markdown).

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

Поддержите комментарий к запросу на вытягивание, нажав кнопку Нравится(рис. 42). Если вы наведете указатель мыши на эту кнопку, вы увидите список всех пользователей, которым понравился комментарий.

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

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

Поддержка фильтрации по пути для уведомлений Git

Вместо получения уведомлений для всех папок в репозитории теперь можно настроить получение уведомлений при создании участниками команды запросов на включение внесенных изменений или при отправке кода только в те папки, которые вас интересует. При создании настраиваемых подписок на уведомления по электронной почте для Git push или Git pull запросов вы увидите новый параметр, который позволяет фильтровать эти уведомления по пути к папке (рис. 44).

Обновлены шаблоны электронной почты для рабочих процессов pull request.

Мы обновили оповещения по электронной почте для pull-запросов, сделав их более краткими, понятными и действенными (рис. 45). Строка темы начинается с названия запроса и дополнительной информации, такой как имя репозитория, тогда как идентификатор указывается в конце. Имя автора было добавлено в тему, чтобы упростить применение правил и фильтров, основанных на имени пользователя, создавшего запрос.

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

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

Обновленные шаблоны электронной почты для push-уведомлений

Push-уведомления были обновлены в соответствии с новыми шаблонами электронной почты, которые стали более понятными, краткими и полезными в практическом плане (рис. 47). Строка темы помогает четко отличать push-уведомления по электронной почте, определять ветку, репозиторий, автора и обобщать количество фиксаций, включенных в push. Кроме того, благодаря этим изменениям стало проще создавать правила и фильтры для управления уведомлениями по электронной почте.

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

Вики-сайт

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

Ниже перечислены некоторые основные функции новых вики-сайтов.

• Упрощенный интерфейс редактирования с помощью синтаксиса Markdown.
• На новой странице можно указать название и добавить содержимое. (Рис. 49)

• Поддержка HTML-тегов в Markdown (рис. 50).

• Удобное изменение размеров изображения в папке Markdown (рис. 51).

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

• Обновление вики-страниц в автономном режиме для опытных пользователей.

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

Создание вики-страницы по неработающей ссылке

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

Создание глубинных ссылок на вики-странице

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

• На той же странице: [text to display](#section-name)
• На другой странице: [text to display](/page-name#section-name)

Расширение Wiki на платформе Marketplace теперь устарело. Если вы уже используете расширение "Вики-сайт", то можете перенести свои вики-страницы на новый вики-сайт с помощью этого средства миграции. Дополнительные сведения о переносе существующих вики-страниц на новый вики-сайт.

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

Обновления интерфейса управления пакетами

URL пакетов теперь работают с именем и версией пакета вместо использования идентификаторов GUID. Это упрощает самостоятельное создание URL-адресов пакетов (рис. 55). Формат: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Теперь вы можете скрывать удаленные версии пакетов (рис. 56) от всех пользователей веб-канала (больше никаких зачеркнутых пакетов).

Любое действие, которое можно было выполнить на странице сведений о пакете, теперь можно выполнить из контекстного меню в списке пакетов.

Список пакетов содержит новый столбец Последнее обновление(рис. 57) с удобными для восприятия датами, что позволяет легко найти недавно обновленные пакеты.

Пакеты Maven

Мы запустили поддержку размещения артефактов Maven в TFS 2018 (рис. 58). Артефакты Maven позволяют разработчикам Java легко совместно использовать код и компоненты. Ознакомьтесь с руководством по началу работы, в котором описано предоставление совместного доступа к артефактам Maven с помощью управления пакетами.

Новая унифицированная задача NuGet

Мы объединили задачи Восстановление NuGet, Упаковщик NuGet и Издатель NuGet в одну задачу сборки NuGet, чтобы обеспечить дополнительное согласование с остальной библиотекой задач сборки; новая задача использует NuGet 4.0.0 по умолчанию. Соответственно, старые задачи признаны нерекомендуемыми, и мы советуем вам перейти на новую задачу NuGet в любое удобное время. Это изменение совпадает с волной улучшений, описанных ниже. Доступ к ним можно будет получить только с помощью объединенной задачи.

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

Параметр NuGet "Разрешить пропуск дубликатов"

Мы получили от пользователей NuGet много отзывов о том, что они создают наборы пакетов, только некоторые из которых могут иметь обновления (и, следовательно, измененные номера версий). Задача сборки NuGet включает новый параметр Разрешить пропуск дубликатов, который позволяет продолжить выполнение задачи при попытке принудительной отправки пакетов в веб-канал VSTS/TFS, где эта версия уже используется.

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

При создании проекта npm в Windows, Linux или Mac новая задача сборки NPM будет работать одинаково эффективно. Мы также реорганизовали задачу, чтобы упростить установку npm и публикацию npm. Для режимов установки и публикации мы упростили получение учетных данных, чтобы учетные данные для реестров, перечисленных в .npmrc-файле проекта, можно было безопасно хранить в конечной точке службы. Кроме того, если вы используете канал VSTS или TFS, мы предоставляем инструмент выбора, который позволяет вам выбрать канал, после чего создается .npmrc с необходимыми учетными данными, которые используются агентом сборки.

Maven теперь поддерживает каналы с проверкой подлинности

В отличие от NuGet и npm, задача сборки Maven ранее не работала с каналами с аутентификацией. Мы обновили задачу Maven, чтобы вы могли легко работать с потоками VSTS/TFS (рис. 60).

Задача dotnet поддерживает авторизированные каналы и веб-приложения

В следующей основной версии задачи dotnet (2.x) представлены решения для многих запросов из ваших отзывов и устранен ряд ошибок, которые мы отслеживали на протяжении некоторого времени. Это включает следующее:

1. Во-первых, задача dotnet теперь поддерживает источники пакетов с проверкой подлинности, такие как управление пакетами, поэтому вам больше не требуется использовать задачу NuGet для восстановления пакетов из частных источников пакетов.
2. Поведение поля Путь к проекту изменилось в версии 2.0. В предыдущих версиях задачи, если не удавалось найти файл проекта, соответствующий указанному шаблону, задача записывала в журнал предупреждение, а затем успешно выполнялась. В таких случаях иногда может быть сложно понять, почему сборка выполнена успешно при этом зависимости не восстановлены. Теперь задача завершается ошибкой, если не удается найти файлы проектов, соответствующие указанному шаблону. Это согласуется с поведением других задач и упрощает понимание и использование.
3. В предыдущих версиях команды публикации задачи задача изменяла выходной путь, помещая все файлы в папку, которой присваивалось имя, соответствующее имени файла проекта, даже в том случае, если был передан явный выходной путь. Это затрудняло создание цепочки команд. Теперь вы можете контролировать выходной путь к файлу.

Мы также выпустили новую задачу Установщик dotnet, которая управляет версией dotnet, доступной в PATH и используемой новой dotnet задачей. Таким образом, чтобы использовать более новую версию dotnet, просто добавьте задачу Установщик dotnet в начало сборки.

Работа вне учетной записи или коллекции

Теперь стало проще работать с веб-каналами (рис. 61) за пределами вашего сервера TFS или учетной записи VSTS, будь то каналы системы управления пакетами в других учетных записях VSTS или серверах TFS или каналы, не относящиеся к управлению пакетами, такие как NuGet.org/npmjs.com, Artifactory или MyGet (рис. 60). Выделенные типы конечной точки службы для NuGet и npm упрощают ввод правильных учетных данных и позволяют задаче сборки эффективно работать в операциях загрузки и отправки пакетов.

Выборщик фидов для фидов VSTS/TFS

Мы всегда рекомендуем добавлять файл конфигурации (например, NuGet.Config, .npmrc и т. д.) в систему контроля версий, чтобы в репозитории была запись о происхождении ваших пакетов. Тем не менее мы знаем, что существуют ситуации, когда такое решение не является оптимальным. Поэтому мы добавили новый параметр Использовать пакеты из этого веб-канала VSTS или TFS, который позволяет выбрать веб-канал и автоматически создать файл конфигурации для этого шага сборки (рис. 62).

Сборка и релиз

Сборки XAML

В Team Foundation Server 2015 была представлена веб-ориентированная кроссплатформенная система сборок. Сборки XAML не поддерживаются в TFS 2018 RTW или обновлении 1, но они повторно включены в TFS 2018 с обновлением 2. Мы рекомендуем выполнить перенос сборок XAML. Если вы еще не готовы к миграции и вам нужно по-прежнему использовать сборки XAML, перейдите на TFS 2018 с обновлением 2.

При обновлении до TFS 2018 RTW или обновления 1 происходит следующее.

• Если в коллекции командных проектов есть данные сборок XAML, вы получите предупреждение об удалении компонентов сборки XAML.

• Вы сможете просматривать завершенные сборки XAML, но не сможете добавлять новые сборки в очередь.

• В TFS 2018 не появится новая версия контроллера или агента сборки XAML.

При обновлении до TFS 2018 с обновлением 2 происходит следующее.

• Если в коллекции командных проектов есть данные сборок XAML, вы получите предупреждение о нерекомендуемых компонентах сборки XAML.

• Чтобы изменить определения сборки XAML или поставить в очередь новые сборки XAML, потребуется использовать Visual Studio или Team Explorer 2017.

• Если вам нужно создать агенты сборки XAML, установите их с помощью установщика агента сборки TFS 2015.

Экспорт и импорт определений сборок

Определения сборок реализуются внутренним образом как JSON-файлы, чтобы можно было видеть сведения об изменениях в журнале файла. Функция клонирования и создания шаблонов на основе определений сборки уже доступна, но многим пользователям требовалась возможность копировать логику сборки CI и повторно использовать ее в других командных проектах. Этот запрос входил в 10 основных запросов на UserVoice.

Мы рады сообщить, что теперь это стало возможно (рис. 63 и рис. 64).

Расширения с шаблонами сборок

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

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Полный пример см. здесь: https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Списание задачи в расширении

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

"deprecated": true

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

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

Разрешить внесённым разделам сборки управлять видимостью этих разделов

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

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Просмотрите примеры в репозитории Майкрософт vsts-extension-samples.

Поддержка групп переменных

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

Работа с защищенными файлами, такими как сертификаты Apple

Мы добавили библиотеку защищенных файлов общего назначения (рис. 67).

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

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

Мы также добавили некоторые задачи Apple, использующие эту новую функцию:

• Utility — установка сертификата Apple;

• Утилита: установка профиля Provisioning от Apple.

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

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

Поддержка проверок входных данных задач

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

Новый редактор описания релиза

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

Визуализация конвейера

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

Контекстный интерфейс конфигурации

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

Начало работы с шаблонами развертывания

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

Упрощенное управление переменными выпуска и среды

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

Улучшенный редактор задач и этапов

Все усовершенствования в новом редакторе определений сборок теперь также доступны в редакторе определений выпуска (рис. 72). Находить задачи и добавлять их можно с помощью кнопки Добавить или путем перетаскивания. С помощью перетаскивания можно клонировать задачи или изменять их порядок.

Группы переменных, хранение и вкладка "Параметры"

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

Операции уровня среды можно сохранять как шаблон и использовать их для задания параметров безопасности (рис. 74).

Развертывание виртуальных машин с помощью групп развертывания

Компонент Release Management теперь поддерживает надежное развертывание на нескольких машинах из коробки. Теперь вы можете управлять развертываниями на нескольких компьютерах и выполнять последовательные обновления с гарантированно высоким уровнем доступности приложений.

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

Группа развертывания (рис. 75) представляет собой логическую группу целевых объектов (компьютеров), на каждом из которых установлены агенты. Группы развертывания представляют физические среды, такие как однопользовательская разработка, многомашинное тестирование и кластер машин для UAT/Prod. Они также указывают контекст безопасности для физических сред.

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

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

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

Эта функция теперь является неотъемлемой частью системы управления выпусками. Дополнительные лицензии не требуются.

Улучшенный пользовательский интерфейс групп развертывания

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

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

Ссылки группы задач

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

При попытке удалить группу задач, на которую все еще есть ссылки, выводится предупреждение и ссылка на эту страницу.

Управление версиями группы задач

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

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

Импорт и экспорт группы задач

Хотя группы задач можно было повторно использовать в проекте, процесс повторного создания группы задач для нескольких проектов и учетных записей представлял сложности. Функции импорта и экспорта группы задач (рис. 83), как и ранее для определений релизов, теперь поддерживают возможность экспорта в виде файлов JSON и импорта туда, куда вам нужно. Мы также включили возможность вложенных групп задач, которые первоначально разворачиваются при экспорте.

Поддержка нескольких конфигураций в задачах на стороне сервера (без агента)

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

Поддержка переменных в задаче "Вмешательство вручную"

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

Управление выпусками в среде в зависимости от исходной ветви

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

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

Release Management теперь поддерживает использование фильтров артефактов для каждой среды. Это означает, что можно указать выпуски, которые развертываются в каждой среде, когда выполняются условия триггера развертывания (такие как успешная сборка и создание нового выпуска). В разделе Триггер диалогового окна Условия развертывания среды (рис. 87) выберите условия артефакта, такие как исходная ветвь и теги для сборок, которые будут активировать новое развертывание для этой среды.

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

Триггеры релизов для Git-репозиториев, использующихся в качестве источника артефактов

Release Management теперь поддерживает настройку триггера непрерывного развертывания (рис. 89) для репозиториев Git, связанных с определением выпуска в любом из командных проектов одной учетной записи. Это позволяет автоматически триггерить релиз при создании нового коммита в репозитории. Можно также указать ветвь в репозитории Git, для которой коммиты будут инициировать релиз.

Триггеры выпуска: непрерывное развертывание изменений, которые были отправлены в репозиторий Git

Компонент Release Management всегда предоставлял возможность настроить непрерывное развертывание после завершения сборки. Теперь также можно настроить непрерывное развертывание при помощи команды Git Push. Это означает, что можно связать репозитории Git из GitHub и Team Foundation в качестве источников артефактов для определения релиза, а затем автоматически запускать релизы для приложений, например, Node.JS и PHP, которые не требуют участия сборочного процесса и, следовательно, не требуют действия сборки для непрерывного развертывания.

Фильтры ветвей в триггерах окружения

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

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

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

Мы внесли несколько улучшений в задачи на стороне сервера (задачи, которые выполняются на этапе сервера).

Мы добавили новую задачу, которая вызывает любой универсальный интерфейс REST API с HTTP (рис. 91) в составе автоматического конвейера. Например, ее можно использовать для вызова определенной обработки с помощью функции Azure и ожидания ее завершения.

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

Значок состояния выпуска в хабе кода

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

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

Усовершенствования в меню определения сборки при добавлении артефактов

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

Список определений фильтруется: выводятся те определения, которые содержат условие фильтра.

Верните конфигурацию выпуска к предыдущей версии.

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

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

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

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

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

Тестирование

Прекращена поддержка центра лабораторий и потоков автоматического тестирования в Microsoft Test Manager

По мере развития системы управления выпусками и сборками сборки XAML больше не поддерживаются в TFS 2018, и, соответственно, мы обновляем поддержку использования Microsoft Test Manager (MTM) с TFS. Использование центра тестирования и центра лабораторий в Microsoft Test Manager для выполнения автоматических тестов больше не поддерживается в TFS начиная с TFS 2018. Если вы не готовы к отказу от сборок XAML и центра лабораторий, не выполняйте обновление до TFS 2018.

Влияние обновления на TFS 2018 см. ниже.

Центр лабораторий

• Больше не поддерживается:
  • Контроллеры Test Controller нельзя зарегистрировать в Team Foundation Server для создания лабораторных сред и управления ими.
  • Все существующие контроллеры Test Controller, зарегистрированные в Team Foundation Server, будут отключены и существующие лабораторные среды будут отображаться как неготовые.
• Рекомендуемая альтернатива:
  • Можно подключиться к серверу SCVMM с помощью расширения TFS SCVMM, создать и настроить виртуальные машины и запустить рабочие процессы на этих машинах. Дополнительные сведения см. в статье How to perform Lab management operations in Build and Release (Выполнение операций управления лабораторией в выпуске и сборке).

Автоматическое тестирование

• Больше не поддерживается:
  • Рабочие процессы автоматического тестирования, которые зависят от контроллеров тестирования и лабораторных сред, такие как рабочий процесс "сборка-развертывание-тестирование" XAML или запуск автоматических тестов из плана тестирования с помощью MTM, больше не поддерживаются.
• Рекомендуемые варианты:
  • Автоматические тесты можно запускать в процессе сборки и выпуска.
  • Автоматические тесты можно выполнять из плана тестирования с помощью центра тестирования.

Тестирование вручную

• Все сценарии тестирования вручную по-прежнему полностью поддерживаются. Хотя ручные тесты можно выполнять с помощью MTM в TFS 2018, лабораторные среды нельзя использовать для выполнения ручных тестов.
• Для всех сценариев тестирования вручную мы настоятельно рекомендуем использовать центр тестирования в веб-интерфейсе TFS.

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

Основываясь на отзывах, которые мы получили от команд, использующих произвольное тестирование, мы улучшаем прослеживаемость ссылок при регистрации ошибок, задач и тестовых случаев из расширения "Тестирование и обратная связь". Ошибки и задачи, созданные в процессе изучения требований, теперь созданы с использованием того же пути области и итерации, как требования, вместо значений команды по умолчанию. Тестовые случаи, созданные при изучении требований, теперь будут связываться через ссылку Тесты <-> Тестируемые Тестами, а не через ссылку Родительский объект <-> Дочерний объект. Это позволит автоматически добавлять связанные тестовые случаи в наборы тестов на основе требований. И, наконец, рабочие элементы, созданные без конкретной проработки какого-либо требования, сохраняются в итерации команды по умолчанию вместо текущей итерации, поэтому новые рабочие элементы не поступают в текущую итерацию по завершении планирования спринта.

Фильтры для рабочих элементов тест-кейсов в планах и наборах тестов в Test Hub

Помимо фильтров в полях Тест, таких как Результат, Конфигурация и Тест-инженер, теперь доступна фильтрация по полям рабочих элементов в тестовых случаях, таких как Название, Состояние и Кому назначено(рис. 98).

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

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

Поддержка разметки Markdown для комментариев к тестовым запускам и результатам тестов.

Мы добавляем поддержку форматирования комментариев Тестовый запуск и Результат теста с использованием синтаксиса Markdown. Эту функцию можно использовать, чтобы создать форматированный текст или быстрые ссылки на URL-адреса в комментариях. Комментарии Результат теста можно обновить на странице Сводка результатов, используя функцию Обновление анализа, и комментарии Запуск теста на странице Сводка запуска с функцией Обновить комментарии в тестовом центре.

Добавьте ссылку на существующий баг для проваленного теста

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

Отправка вложений к тестовым запускам и результатам тестов

В тестовые запуски или результаты тестов теперь в качестве дополнительной информации можно вкладывать файлы, например снимки экрана и файлы журналов. До сих пор эта возможность была доступна только в клиенте Microsoft Test Manager (MTM), из-за чего приходилось переключаться между центром тестирования в Visual Studio Team Services или Team Foundation Server и клиентом MTM.

Пакетная обработка тестов

В области управления сборками и выпусками для задачи теста Visual Studio доступны параметры, с помощью которых можно управлять тем, как должны группироваться (объединяться в пакеты) тесты для эффективного выполнения. Тесты можно группировать двумя способами:

1. в соответствии с числом тестов и агентов, участвующих в запуске; при этом тесты просто объединяются в несколько пакетов определенного размера;
2. Основано на времени предыдущего выполнения тестов, при этом учитывается прошлое время выполнения для создания пакетов тестов таким образом, чтобы каждый пакет имел приблизительно одинаковое время выполнения (рис. 100). Быстро выполняющиеся тесты объединяются в один пакет, в то время как долго выполняющиеся тесты могут быть в отдельном пакете. Чтобы свести общее время тестирования к минимуму, этот параметр можно применять в сочетании с настройкой, подразумевающей этап использования нескольких агентов.

Выполнение веб-тестов с помощью задачи VSTest

С помощью задачи теста Visual Studio веб-тесты, также называемые веб-тестами производительности, теперь можно выполнять в рамках конвейера CI/CD. Для выполнения веб-тестов их можно указать во входных данных сборки задачи. Любой рабочий элемент тестового случая, связанная автоматизация которого связана с веб-тестом, можно также выполнить, выбрав в задаче план тестирования или набор тестов (рис. 101).

Результаты веб-теста доступны в виде вложения в результаты теста (рис. 102). Их можно скачать для автономного анализа в Visual Studio.

Эта возможность зависит от изменений в платформе тестирования Visual Studio и требует установки Visual Studio 2017 с обновлением 4 в агенте сборки или выпуска. Веб-тесты нельзя выполнять с помощью предыдущих версий Visual Studio.

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

Мини-приложение диаграмм для планов тестирования и наборов тестов

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

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

Мы добавляем поддержку одного из самых популярных предложений ручного тестирования — создания скриншотов настольных приложений в Web Test Runner в центре Test. До сих пор для создания снимков экрана настольных приложений приходилось использовать Test Runner в Microsoft Test Manager. Для использования этой функции необходимо установить расширение тестирования и обратной связи. Сейчас реализуется поддержка браузера Chrome, а в скором времени появится поддержка Firefox.

Прекращение поддержки расширения TFS для SharePoint

В TFS 2018 и более поздних версиях прекращается поддержка расширение TFS для SharePoint. Кроме того, экраны, используемые для настройки интеграции между сервером TFS и сервером SharePoint, удалены из консоли администрирования Team Foundation.

Мы создали решение, позволяющее отключить интеграцию на сервере SharePoint. Дополнительные сведения см. в записи о дальнейшем развитии интеграции Team Foundation Server с SharePoint.

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

Современные команды разработчиков сильно зависят от совместной работы. Людям требуется место для отслеживания активности (уведомлений) и обсуждения (чаты). Несколько лет назад мы обратили внимание на эту тенденцию и приступили к созданию комнат команд для поддержки таких сценариев. С того времени на рынке появилось много решений для совместной работы. Прежде всего, следует отметить успех решения Slack. Кроме того, недавно было объявлено о выпуске Microsoft Teams.

Учитывая наличие большого числа хороших решений, которые отлично интегрируются с Team Foundation Server и Visual Studio Team Services, в январе мы объявили о планах по удалению компонента "Комната команды" из TFS 2018 и Visual Studio Team Services.

Как обстоят дела?

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