Заметки о выпуске версии-кандидата 1 Team Foundation Server 2018

Last Update: 25.09.2017

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

Download the latest version of Team Foundation Server

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


Отзывы

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


Дата выпуска: 30 августа 2017 г.

Сводка: обновления Team Server Foundation в версии-кандидате 1 TFS 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 и более поздних версиях перенаправление на веб-интерфейс выполняется автоматически.

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

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

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

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

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

Вилки

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

Git forks

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

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

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

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

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

Turn off web editing

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

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

Web editing not allowed dialog

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

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

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

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

Stale branches

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

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

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

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

Search for deleted branches

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

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

Restore deleted branches

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

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

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

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

Search for a commit

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

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

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

Pull request callout

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

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

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

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

Find a file or folder

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

Filtered view

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

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

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

Pushes page

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

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

Commits page

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

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

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

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

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

View Git tags

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

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

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

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

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

Delete git tags

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

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

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

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

Filter Git tags

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

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

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

Git tag security

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

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

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

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

Complete linked work items

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

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

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

Reset votes setting

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

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

Reset votes in timeline

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

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

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

Find file or folder in pull request

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

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

Find results

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

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

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

PR comment filtering

Рис. 28. Фильтрация комментариев к запросу на включение внесенных изменений

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

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

View original diff

Рис. 29. Просмотр различий с исходным комментарием

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

Update badge

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

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

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

Hide comments

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

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

Collapsed comments

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

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

Collapsed comment tooltip

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

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

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

Task list toolbar

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

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

Task list

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

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

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

Like pull request comments

Рис. 36. Отметка "Нравится" для комментариев к запросу на включение внесенных изменений

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

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

Cancel auto-complete dialog

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

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

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

Path filtering for notifications

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

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

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

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

Improved email template

Рис. 39. Улучшенный шаблон сообщения

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

Email call-to-action

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

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

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

Когда служба передает данные в API состояния для запроса на вытягивание, эти данные сразу же появляются в представлении сведений о запросе в новом разделе Состояние (рис. 41). В разделе состояния отображается описание и создается ссылка на URL-адрес, предоставленный службой. Записи состояния также поддерживают меню действий (...), в которое веб-расширения могут добавить новые действия.

PR status section

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

Само по себе состояние не блокирует завершение запроса — за это отвечает политика. После публикации состояния запроса можно настроить политику. В интерфейсе работы с политикам ветвления доступна новая политика Требовать утверждения от внешних служб. Выберите + Добавить службу, чтобы начать процесс (рис. 42).

Add new policy

Рис. 42. Добавление новой политики для запроса

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

Set status policy

Рис. 43. Настройка политики состояния запроса

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

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

Вики-сайт

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

Wiki page

Рис. 44. Вики-страница запроса на включение внесенных изменений

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

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

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

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

Wiki HTML tags

Рис. 46. HTML-теги вики-сайта запроса на включение внесенных изменений

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

Image resize

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

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

Wiki menu

Рис. 48. Меню вики-сайта запроса на включение внесенных изменений

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

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

Wiki revert button

Рис. 49. Кнопка "Отменить изменения" вики-сайта запроса на включение внесенных изменений

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

Create wiki page

Рис. 50. Создание вики-страницы запроса на включение внесенных изменений

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

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

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

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

Package URL

Рис. 51. URL-адрес пакета запроса на включение внесенных изменений

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

Hide deleted packages

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

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

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

Last pushed column

Рис. 53. Столбец "Последние отправленные"

Пакеты Maven

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

Maven packages

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

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

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

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

Nuget task

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

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

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

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

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

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

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

dotnet task

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

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

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

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

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

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

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

Feeds to use

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

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

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

Feed picker

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

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

Прекращается поддержка сборок 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 см. в этой записи блога.

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

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

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

Export build definition

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

Import build definition

Рис. 60. Импорт определения сборки

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

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

{  "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

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

Deprecated task badge

Рис. 61. Значок устаревшей задачи

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

Deprecated task description

Рис. 62. Описание устаревшей задачи

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

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

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

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

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

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

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

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

Secure files library

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

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

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

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

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

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

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

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

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

Pipeline

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

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

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

Release configuration

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

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

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

Deployment templates

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

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

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

Task editor

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

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

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

Variable groups

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

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

Environment menu

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

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

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

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

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

Deployment groups

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

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

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

Configure deployment groups

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

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

Deployment group progress

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

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

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

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

Task group references

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

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

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

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

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

Save as draft

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

Publish task group as preview

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

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

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

Export task group

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

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

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

Multi configuration of agentless tasks

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

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

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

Manual intervention task

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

Manual intevention pending dialog

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

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

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

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

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

Deployment conditions dialog

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

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

Release summary tip

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

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

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

Release triggers

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

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

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

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

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

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

REST API task

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

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

Task control options

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

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

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

Release status badge

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

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

Deployment options dialog

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

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

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

Add artifact

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

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

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

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

Revert release definition

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

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

Прекращена поддержка центра лабораторий и потоков автоматического тестирования в 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.

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

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

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

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

Test case filters

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

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

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

Test trend chart

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

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

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

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

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

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

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

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

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

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

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


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

Служба импорта баз данных TFS не поддерживает релиз-кандидаты

Служба импорта баз данных TFS для Visual Studio Team Services не поддерживает импорт из релиз-кандидатов TFS. Если вы планируете импортировать базу данных коллекции в Team Services с помощью этой службы, не переводите рабочую базу данных на этот выпуск. Если вы это сделаете, вам нужно будет либо дождаться выпуска RTW-версии и перевести базу данных на нее, либо восстановить и импортировать свою базу данных, созданную в предыдущей версии TFS, из резервной копии.

Задача "Тест Visual Studio 1" версии 1 в сборке или выпуске не может выполнять тесты, используя обновление 3 для Visual Studio 2017

Задача "Тест Visual Studio" версии 1 в сборке или выпуске не может выполнять тесты, используя обновление 3 для Visual Studio 2017. Задача завершается с ошибкой "Не удалось определить расположение файла vstest.console.exe". В качестве решения рекомендуется использовать версию 2 задачи "Тест Visual Studio".