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

Last Update: 22.11.2017

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

Download the latest version of Team Foundation Server

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


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


Отзывы

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


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

Сводка: обновления Team Foundation Server 2018

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

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


Подробные сведения. Новые возможности этого выпуска

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

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

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

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

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

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

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

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

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

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

Mobile work item query

Рис. 1. Запрос рабочих элементов с мобильного устройства

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

Mobile work item form

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

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

Mobile navigation

Рис. 3. Навигация на мобильных устройствах

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

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

Filtering on query

Рис. 4. Фильтрация по запросам

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

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

Hidden field

Рис. 5. Скрытое поле на карте канбана

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

Update hidden field

Рис. 6. Изменение скрытого поля на карте канбана

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

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

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

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

Inline add on delivery plans

Рис. 7. Встроенные планы доставки надстроек

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

Вилки

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

Git forks

Рис. 8. Вилки Git

GVFS

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

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

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

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

New folder option

Рис. 9. Команда для создания папки

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

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

New file dialog

Рис. 10. Диалоговое окно создания файла

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

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

File minimap

Рис. 11. Мини-карта файла

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

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

Bracket matching

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

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

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

Toggle white space

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

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

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

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

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

Примечание

Это изменение не затрагивает редактирование файла сведений (README) на странице обзора проекта.

Turn off web editing

Рис. 14. Отключение веб-редактирования

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

Web editing not allowed dialog

Рис. 15. Диалоговое окно "Веб-редактирование запрещено"

Это режим был разработан на основе связанных предложений.

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

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

Stale branches

Рис. 16. Устаревшие ветви

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

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

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

Search for deleted branches

Рис. 17. Поиск удаленных ветвей

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

Restore deleted branches

Рис. 18. Восстановление удаленных ветвей

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

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

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

Search for a commit

Рис. 19. Поиск фиксации

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

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

Pull request callout

Рис. 20. Выноска запроса на вытягивание

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

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

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

Find a file or folder

Рис. 21. Поиск файла или папки

Filtered view

Рис. 22. Отфильтрованное представление дерева фиксаций

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

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

Pushes page

Рис. 23. Страница "Push-уведомления"

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

Commits page

Рис. 24. Страница "Фиксации"

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

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

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

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

View Git tags

Рис. 25. Просмотр тегов Git

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

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

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

Предупреждение

Удалять теги удаленных репозиториев необходимо с осторожностью.

Delete git tags

Рис. 26. Удаление тегов Git

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

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

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

Filter Git tags

Рис. 27. Фильтрация тегов Git

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

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

Git tag security

Рис. 28. Безопасность тегов Git

Дополнительные сведения о тегах Git см. в блоге Microsoft DevOps.

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

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

Complete linked work items

Рис. 29. Завершение связанных рабочих элементов

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

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

Reset votes setting

Рис. 30. Параметр сброса голосов

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

Reset votes in timeline

Рис. 31. Сброс голосов на временной шкале

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

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

Find file or folder in pull request

Рис. 32. Поиск файла или папки в запросе на вытягивание

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

Find results

Рис. 33. Поиск результатов

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

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

PR comment filtering

Рис. 34. Фильтрация комментариев к запросу на вытягивание

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

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

View original diff

Рис. 35. Просмотр исходного несовпадения

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

Update badge

Рис. 36. Значок изменения

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

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

Hide comments

Рис. 37. Скрытие комментариев

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

Collapsed comments

Рис. 38. Свернутые комментарии

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

Collapsed comment tooltip

Рис. 39. Подсказка свернутого комментария

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

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

Task list toolbar

Рис. 40. Панель инструментов списка задач

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

Task list

Рис. 41. Список задач

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

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

Like pull request comments

Рис. 42. Отметка "Нравится" для комментариев к запросу на вытягивание

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

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

Cancel auto-complete dialog

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

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

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

Path filtering for notifications

Рис. 44. Фильтрация уведомлений по пути

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

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

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

Improved email template

Рис. 45. Улучшенный шаблон электронной почты

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

Email call-to-action

Рис. 46. Призыв к действию в сообщении

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

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

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

Push template

Рис. 47. Шаблон сообщения об отправке

Вики-сайт

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

Wiki page

Рис. 48. Вики-страница запроса на вытягивание

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

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

Title wiki

Рис. 49. Заглавная вики-страница запроса на вытягивание

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

Wiki HTML tags

Рис. 50. HTML-теги вики-сайта запроса на вытягивание

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

Image resize

Рис. 51. Изменение размера изображения запроса на вытягивание

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

Wiki menu

Рис. 52. Меню вики-сайта запроса на вытягивание

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

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

Wiki revert button

Рис. 53. Кнопка "Отменить изменения" вики-сайта запроса на вытягивание

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

Create wiki page

Рис. 54. Создание вики-страницы запроса на вытягивание

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

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

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

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

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

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

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

Package URL

Рис. 55. URL-адрес пакета запроса на вытягивание

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

Hide deleted packages

Рис. 56. Скрытие удаленных пакетов

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

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

Last pushed column

Рис. 57. Столбец "Последняя принудительная отправка"

Пакеты Maven

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

Maven packages

Рис. 58. Пакеты Maven

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

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

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

Nuget task

Рис. 59. Задача NuGet

См. дополнительные сведения об использовании в вашей сборке новейших версий NuGet в блоге Microsoft DevOps.

Параметр 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 task

Рис. 60. Задача dotnet

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

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

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

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

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

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

Feeds to use

Рис. 61. Используемый веб-канал

Средство выбора веб-канала для каналов VSTS/TFS

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

Feed picker

Рис. 62. Средство выбора веб-канала

Сборка и выпуск

Прекращается поддержка сборок XAML

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

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

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

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

  • В TFS 2018 нет новой версии агента или контроллера сборки XAML, и настроить старую версию агента или контроллера сборки XAML для работы с TFS 2018 нельзя.

Объяснение планового устаревания сборки XAML см. в записи блога Развитие возможностей автоматизации сборки в TFS и Team Services.

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

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

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

Export build definition

Рис. 63. Экспорт определения сборки

Import build definition

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

Deprecated task badge

Рис. 65. Значок нерекомендуемой задачи

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

Deprecated task description

Рис. 66. Описание нерекомендуемой задачи

Опубликованные разделы сборки могут управлять видимостью сборки

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

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

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

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

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

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

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

Secure files library

Рис. 67. Библиотека защищенных файлов

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

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

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

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

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

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

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

Дополнительные сведения о назначении и использовании проверок см. на странице репозитория vsts-tasks.

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

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

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

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

Pipeline

Рис. 68. Конвейер выпуска

Пользовательский интерфейс конфигурации в контексте

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

Release configuration

Рис. 69. Конфигурация выпуска

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

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

Deployment templates

Рис. 70. Шаблоны развертывания

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

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

Simplified management of variables

Рис. 71. Упрощенное управление переменными

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

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

Task editor

Рис. 72. Редактор задач

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

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

Variable groups

Рис. 73. Группы переменных

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

Environment menu

Рис. 74. Меню "Среда"

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

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

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

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

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

Deployment groups

Рис. 75. Группы развертываний

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

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

Configure deployment groups

Рис. 76. Настройка групп развертываний

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

Deployment group progress

Рис. 77. Ход выполнения группы развертываний

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

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

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

Deployment groups UI

Рис. 78. Пользовательский интерфейс групп развертывания

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

Deployment groups UI tags

Рис. 79. Теги в пользовательском интерфейсе групп развертывания

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

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

Task group references

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

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

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

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

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

Save as draft

Рис. 81. Сохранение группы задач в качестве черновика

Publish task group as preview

Рис. 82. Публикация группы задач в качестве предварительной версии

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

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

Export task group

Рис. 83. Экспорт группы задач

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

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

Multi configuration of agentless tasks

Рис. 84. Несколько конфигураций задач без агента

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

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

Manual intervention task

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

Manual intevention pending dialog

Рис. 86. Диалоговое окно "Ожидается вмешательство вручную"

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

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

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

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

Deployment conditions dialog

Рис. 87. Диалоговое окно "Условия развертывания"

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

Release summary tip

Рис. 88. Подсказка сводки по выпуску

Триггеры выпуска для репозиториев Git как источник артефакта

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

Release triggers

Рис. 89. Триггеры выпуска

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

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

Фильтры ветвей в триггерах среды

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

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

Branch filters

Рис. 90. Фильтры ветвей

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

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

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

REST API task

Рис. 91. Задача REST API

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

Task control options

Рис. 92. Параметры управления задачей

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

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

Release status badge

Рис. 93. Значок состояния выпуска

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

Deployment options dialog

Рис. 94. Диалоговое окно параметров развертывания

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

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

Add artifact

Рис. 95. Добавление артефактов

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

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

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

Revert release definition

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

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

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

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

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

Release notifications

Рис. 97. Уведомления о выпусках

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

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

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

По мере развития системы управления выпусками и сборками поддержка сборок XAML прекращена в TFS 2018, соответственно, мы обновляем поддержку Microsoft Test Manager (MTM) в Team Foundation Server. Использование центра тестирования и центра лабораторий в 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 (Выполнение операций управления лабораторией в выпуске и сборке).
Автоматическое тестирование
Тестирование вручную
  • Все сценарии тестирования вручную по-прежнему полностью поддерживаются. Хотя ручные тесты можно выполнять с помощью MTM в TFS 2018, лабораторные среды нельзя использовать для выполнения ручных тестов.
  • Для всех сценариев тестирования вручную мы настоятельно рекомендуем использовать центр тестирования в веб-интерфейсе TFS.

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

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

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

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

Test case filters

Рис. 98. Фильтры тестовых случаев

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

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

Test trend chart

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

Поддержка форматирования разметки Markdown для комментариев "Тестовый запуск" и "Результат теста"

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

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

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

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

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

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

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

Test batching

Рис. 100. Пакетная обработка тестов

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

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

Test selection

Рис. 101. Выбор тестов

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

Test summary

Рис. 102. Сводка теста

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

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

Пример использования этой возможности с нагрузочным тестированием см. в кратком руководстве по нагрузочному тестированию приложения в облаке с помощью Visual Studio и Visual Studio Team Services.

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

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

Chart widget

Рис. 103. Мини-приложение диаграмм

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

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

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

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

Примечание

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

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

Прекращение поддержки комнат команд

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

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


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