Заметки о выпуске Team Foundation Server 2018
Сообщество разработчиков | Требования к системе и совместимость | Условия лицензии | Блог по TFS DevOps | Хэши SHA-1 | Заметки о выпуске последней версии Visual Studio 2019
Примечание.
Если вы открываете локализованную версию этой страницы и хотите просмотреть актуальные материалы, посетите страницу "Заметки о выпуске" на английском языке. Язык этой страницы можно изменить, щелкнув значок глобуса в нижнем колонтитуле страницы и выбрав нужный язык.
Эта статья содержит сведения о Team Foundation Server 2018. Нажмите кнопку, чтобы скачать файлы.
Дополнительные сведения о Team Foundation Server 2018 см. на странице Требования к Team Foundation Server и совместимость. Вы можете скачать другие продукты TFS 2018 на странице visualstudio.com/downloads.
Дополнительные сведения см. на странице по установке TFS.
Дата выпуска: 15 ноября 2017 г.
Сводка новых возможностей в TFS 2018
Мы добавили в Team Foundation Server 2018 много новых и полезных функций. Вот некоторые из них:
- улучшен веб-интерфейс мастера создания проектов и диспетчера шаблонов процессов;
- Теперь можно настроить заголовок формы рабочего элемента.
- оптимизирована форма рабочих элементов для мобильных устройств;
- добавлена поддержка вилок Git;
- Вы можете управлять большими репозиториями Git с помощью GVFS.
- добавлена возможность просмотра, фильтрации, удаления и настройки безопасности тегов Git;
- в редактирование веб-кода добавлена мини-карта файлов, сопоставление скобок и переключение отображения пробелов;
- реализованы многочисленные улучшения запросов на включение внесенных изменений;
- реализован новый улучшенный интерфейс работы с вики-сайтами;
- добавлена поддержка пакетов Maven;
- добавлена возможность импортировать и экспортировать определения сборок, а также приостанавливать их;
- новый редактор определений выпуска включен по умолчанию;
- добавлена возможность использования развертывания виртуальных машин;
- улучшена прослеживаемость произвольного тестирования.
- Добавлена пакетная обработка тестов.
- Теперь вам доступно мини-приложение с диаграммами планов тестирования и наборов тестов.
Видео о новых возможностях в TFS 2018
Сборка XAML
Изначально Сборка XAML была отмечена как удаленная из TFS 2018 RTW и обновления 1. Однако из-за этого очень многим клиентам не удалось обновить ее или пришлось обращаться в службу поддержки, чтобы повторно включить ее после обновления. В TFS 2018 с обновлением 2 сборка XAML включена, но использовать ее не рекомендуется. Это значит, что мы больше не занимаемся разработкой сборки XAML, и Microsoft Test Manager (MTM) больше не поддерживает сборки XAML. Рекомендуется перейти на новые форматы определений сборок. Вы можете по-прежнему подключаться к контроллерам XAML и запускать сборки XAML в TFS 2018 с обновлением 2. Дополнительные сведения
Компоненты, удаленные в TFS 2018 RTW
- прекращена поддержка центра лабораторий и потоков автоматического тестирования в Microsoft Test Manager;
- отключено расширение TFS для SharePoint;
- удален компонент Комната команды.
Подробные сведения о новых возможностях в TFS 2018
Отслеживание рабочих элементов
Мастер создания проектов в Интернете
Мы улучшили процесс создания командного проекта через веб-интерфейс. Теперь он включает большую часть функций, доступных при создании командного проекта в клиенте Visual Studio. Преимущество веб-интерфейса в том, что вам не требуется соответствующая версия Visual Studio. Разница в использовании Visual Studio и веб-версии заключается в том, что при работе с веб-версией нельзя подготовить отчеты в SSRS. При использовании веб-версии процесса создания командного проекта можно выполнить команду tfsconfig на уровне приложения для подготовки или обновления отчетов SSRS.
Диспетчер шаблонов процессов в Интернете
В TFS 2018 для отправки шаблонов процессов можно использовать веб-интерфейс. Работать с веб-интерфейсом гораздо проще, так как нет необходимости устанавливать соответствующую версию Visual Studio для взаимодействия с вашими шаблонами процессов. В обновлении 4 для Visual Studio 2017 и более ранних версиях по-прежнему отображается диалоговое окно диспетчера шаблонов процессов, хотя мы рекомендуем использовать веб-интерфейс. В обновлении 5 для Visual Studio 2017 и более поздних версиях перенаправление на веб-интерфейс выполняется автоматически.
Настройка заголовка формы рабочего элемента
Теперь можно настроить область заголовка формы рабочего элемента, заменив существующие или скрыв маловажные элементы управления. Таким образом можно заменить путь к области на пользовательское поле команды, скрыть поле итерации, если команды больше ориентированы на работу с канбаном, и заменить поле причины на пользовательское поле. Скрыть или заменить поле состояния невозможно.
Совет
Дополнительные сведения см. в документации по элементам WebLayout и Control.
Форма рабочего элемента для мобильных устройств
У нас есть полноценный процесс, в котором оптимизирован интерфейс рабочих элементов (рис. 1). Он позволяет легко работать с элементами, которые были вам назначены, которые вы отслеживаете или просматривали либо недавно изменяли, на телефоне.
Наряду с привлекательным внешним видом, этот интерфейс поддерживает оптимизированные элементы управления для всех типов полей (рис. 2).
Новая реализация навигации на мобильных устройствах (рис. 3) позволяет пользователям связываться с другими компонентами TFS, поддерживающими мобильный доступ, и вернуться на полнофункциональный классический сайт, если им требуется взаимодействие с другими центрами.
Фильтрация по невыполненной работе, канбан-доскам, спринтам и запросам
Все функции отслеживания рабочих элементов в таблице (запросы, невыполненная работа, канбан-доски, невыполненная работа по спринтам и управление тестовыми случаями) теперь используют общую согласованную функцию фильтрации (рис. 4). Помимо применения фильтра по ключевым словам для отображаемых столбцов и выбора тегов, можно также использовать фильтрацию по типам рабочих элементов, состояниям и полю "Кому назначено", что позволяет быстрее найти искомые рабочие элементы.
Развертывание для отображения пустых полей на карте канбана
Сейчас вы можете добавлять дополнительные поля на карту, а затем скрывать пустые поля (рис. 5) в параметрах доски, чтобы удалить с доски ненужные элементы. Недостаток использования этой функции заключается в том, что после скрытия пустого поля единственный способ изменить это поле — открыть форму рабочего элемента. Благодаря новой функции развертывания на картах канбана вы можете скрывать пустые поля на доске и при этом переходить к изменению определенного поля на карте одним щелчком мыши. Просто наведите указатель мыши на карту и найдите шеврон, направленный вниз, в нижней части карты, чтобы изменить скрытое поле.
Щелкните шеврон, направленный вниз, в нижней части карты, чтобы изменить поле (рис. 6).
Расширения, блокирующие сохранение рабочего элемента
Страницы, группы и пользовательские элементы управления формы рабочего элемента теперь могут блокировать сохранение рабочего элемента для проверки данных и гарантии того, что пользователь указал все необходимые сведения, прежде чем сохранить форму рабочего элемента.
Встроенные планы доставки надстроек
Идеи по улучшению продукта могут возникнуть в любой момент, поэтому мы упростили добавление новых функций непосредственно в планы доставки (рис. 7). Просто нажмите кнопку Создать элемент, появляющуюся при наведении указателя мыши, введите имя и нажмите клавишу ВВОД. Создана функция с требуемыми путем к области и путем итерации.
Управление версиями
Вилки
В TFS 2018 добавлена поддержка вилок Git (рис. 8). Вилка — это копия репозитория на стороне сервера. Используя вилки, вы можете разрешить широкому кругу пользователей принимать участие в вашем репозитории, не предоставляя им прямой доступ к фиксации. Вместо этого они будут фиксировать свою работу в собственной вилке репозитория. Это дает вам возможность проверять их изменения в запросе на включение внесенных изменений до принятия этих изменений в центральном репозитории.
GVFS
Теперь поддерживается виртуальная файловая система Git (GVFS). GVFS позволяет масштабировать репозитории Git до миллионов файлов благодаря виртуализации и оптимизации работы Git в файловой системе.
Создание папки в репозитории с помощью веб-службы
Теперь вы можете создавать папки в репозиториях Git и TFVC через Интернет (рис. 9). Эта функция пришла на смену расширению для управления папками, которое будет выводиться из использования.
Чтобы создать папку, нажмите Создать > Папка в панели команд или в контекстном меню:
При использовании TFVC необходимо указать имя папки, а затем вернуть ее. При использовании Git необходимо также указать имя файла, так как пустые папки не допускаются, при необходимости изменить файл, а затем зафиксировать его.
Кроме того, при работе с Git в диалоговом окне Новый файл(рис. 10) теперь можно вводить символы косой черты для создания вложенных папок.
Мини-карта файла
В процессе просмотра или редактирования файла теперь можно просмотреть его мини-карту с краткой информацией о коде (рис. 11). Чтобы включить мини-карту, откройте палитру команд (F1 или щелчок правой кнопкой мыши) и выберите команду Переключить мини-карту.
Сопоставление скобок
При редактировании или просмотре файла справа теперь приводятся указания, помогающие обеспечивать соответствие скобок (рис. 12).
Включение и отключение отображения пробелов
При просмотре или редактировании файла теперь можно включать и отключать отображение пробелов. Функция, позволяющая включать и отключать отображение пробелов при поиске различий, пока находится в разработке. Чтобы отобразить пробелы (рис. 13), откройте палитру команд (F1 или щелчок правой кнопкой мыши) и выберите команду Переключить пробел. Это позволит различать пробелы и символы табуляции.
Параметр для отключения веб-редактирования репозиториев TFVC
Группы разработчиков, которые работают с TFVC, часто используют политики возврата в Visual Studio, чтобы гарантировать высокое качество кода. Тем не менее, так как политики возврата действуют на стороне клиента, к коду, который изменяется через веб-клиент, эти политики не применяются.
Мы получили много запросов на реализацию функции отключения веб-редактирования для защиты от изменений, которые обходят политики возврата. Мы реализовали такую возможность: теперь вы можете отключить веб-редактирование (добавление, удаление, переименование и изменение) для TFVC для отдельного проекта или репозитория.
Чтобы запретить веб-редактирование, со страницы Файлы перейдите на страницу Параметры, а затем — Управление версиями (рис. 14). Щелкните репозиторий TFVC в дереве, перейдите к сводной таблице "Параметры" и снимите флажок Включить веб-редактирование для этого репозитория TFVC. По умолчанию веб-редактирование включено.
Примечание.
Это изменение не затрагивает редактирование файла сведений (README) на странице обзора проекта.
При попытке веб-редактирования проекта, для которого веб-редактирование отключено, вы получите уведомление о том, что эта операция недопустима (рис. 15).
Определение устаревших ветвей
Вы можете обеспечить более четкую организацию репозитория, удаляя ненужные ветви. Таким образом, командам будет проще находить интересующие их ветви и задавать избранные ветви с необходимым уровнем точности. Но при наличии большого числа ветвей в репозитории бывает трудно понять, какие из них являются неактивными и могут быть удалены. Теперь стало гораздо проще выявить "устаревшие" ветви (ветви, указывающие на фиксации старше трех месяцев). Для просмотра устаревших ветвей перейдите к сводной таблице Устарело на странице Ветви(рис. 16).
Поиск удаленной ветви и ее повторное создание
Когда вы случайно удаляете ветвь с сервера, бывает сложно понять, что с ней случилось. Теперь можно выполнить поиск удаленной ветви, узнать, кто и когда удалил ее, и повторно создать ее при необходимости.
Для поиска удаленных ветвей введите полное имя ветви в поле поиска ветви. Поиск вернет все существующие ветви, соответствующие этому тексту. Кроме того, можно выполнить поиск точного совпадения в списке удаленных ветвей. Щелкните ссылку, чтобы найти удаленные ветви (рис. 17).
Если соответствие найдено, вы увидите, кто и когда удалил эту ветвь. Вы также можете восстановить ветвь (рис. 18).
При восстановлении ветви выполняется ее повторное создание в той фиксации, на которую она указывала последней. Но политики и разрешения не восстанавливаются.
Поиск фиксации в ветвях, начинающихся с префикса
При наличии структуры ветвей в иерархическом формате, где все ветви начинаются с текстового префикса, эта функция помогает обнаружить фиксацию во всех ветвях, начинающихся с такого текстового префикса. Например, если вы хотите просмотреть, сделана ли фиксация во всех ветвях, которые имеют префикс dev, введите dev в поле поиска и выберите Поиск в ветвях, начинающихся с dev (рис. 19).
Более подробная выноска запроса на включение внесенных изменений на странице сведений о фиксации
Выноска запроса на вытягивание на странице сведений о фиксации содержит наиболее важные сведения, повышающие эффективность диагностики (рис. 20). Теперь на этой выноске также отображается первый запрос на включение внесенных изменений, представляющий фиксацию для каждой ветви, и запрос на включение внесенных изменений, связанный с ветвью по умолчанию.
Фильтрация представления в виде дерева в коде
Теперь не нужно прокручивать все файлы, которые могли быть изменены фиксацией, чтобы просто получить нужные файлы. Представление в виде дерева сведений о фиксации, запросов на включение внесенных изменений, сведений о наборе отложенных изменений и страницы сведений о наборе изменений теперь поддерживает фильтрацию по файлам и папкам. Это интеллектуальный фильтр, показывающий дочерние файлы в папке при фильтрации по имени папки и свернутое представление файла в виде дерева, показывающее иерархию файлов при фильтрации по имени файла.
Поиск фильтра по файлу или папке в дереве фиксаций (рис. 21) и (рис. 22).
Страница "Обновления ветви" заменена страницей "Push-уведомления"
Страница Обновления ветви обеспечивает огромные преимущества. Тем не менее, она скрыта как сводная таблица в центре журналов. Теперь страница обновлений ветви отображается как центр Push-уведомления (рис. 23) в разделе Код, наряду с центрами Фиксации, Ветви, Теги и Запросы на вытягивание. Новый URL-адрес для страницы push-уведомлений: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Старые URL-адреса будут по-прежнему работать.
В то же время центр Журналы переименован в центр Фиксации (рис. 24), так как в этом разделе теперь отображаются только фиксации. Мы получили отзывы о том, что диагностика неполадок, связанных с фиксациями, представляла трудности, так как в представлении списка фиксаций подробные сведения о времени отображались только по наведению указателя мыши. Теперь в представлении списка фиксаций во всем экземпляре дата и время будут отображаться в формате дд.мм.гг чч:мм. Новый URL-адрес для страницы фиксаций: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Старые URL-адреса будут по-прежнему работать.
Сохранение имени файла при переходе из таблицы "Файлы" на страницу "Фиксации"
Некоторые пользователи сообщали о том, что при фильтрации каталога по определенному файлу в сводной таблице Файлы центра кода с последующим переключением на таблицу Журнал имя файла не сохранялось, если фиксация изменяла более 1000 файлов. Из-за этого приходилось загружать больше файлов и фильтровать их содержимое для поиска нужного файла, что отрицательно сказывалось на производительности. Разработчики обычно работают в одном каталоге, и им требуется сохранять имеющиеся рабочие каталоги для отслеживания изменений. Теперь имя файла сохраняется при переходе между сводными таблицами центра кода независимо от количества файлов, измененных в фиксации. Это означает, что теперь вам не нужно щелкать ссылку Загрузить еще, чтобы найти нужный файл.
Просмотр тегов Git
Вы можете просмотреть все теги в репозитории на странице Теги(рис. 25). Если вы управляете всеми тегами как выпусками, пользователь может посетить страницу тегов, чтобы просмотреть обобщенное представление всех выпусков продукта.
Вы можете легко отличить упрощенные теги от тегов с заметками. Для тегов с заметками наряду со связанной фиксацией отображается средство создания тегов и дата создания, тогда как для упрощенных тегов отображаются только сведения о фиксации.
Удаление тегов Git
Бывают ситуации, когда требуется удалить тег из удаленного репозитория, например из-за опечатки в имени тега или применения тега к неправильной фиксации. Теги можно легко удалить с помощью веб-интерфейса, щелкнув контекстное меню тега на странице Теги и выбрав пункт Удалить тег (рис. 26).
Предупреждение
Удалять теги удаленных репозиториев необходимо с осторожностью.
Фильтрация тегов Git
Для старых репозиториев число тегов может со временем значительно возрасти, кроме того, могут существовать репозитории с иерархией тегов, которая затрудняет их поиск.
Если не удалось найти нужный тег на странице Теги, можно попробовать сделать поиск по имени тега, используя фильтр вверху страницы Теги(рис. 27).
Безопасность тегов Git
Теперь вы можете точно настраивать разрешения на управление тегами для пользователей репозитория. Используя этот интерфейс, вы можете предоставить пользователям разрешение на удаление тегов или управление тегами (рис. 28).
Совет
Дополнительные сведения о тегах Git см. в блоге Microsoft DevOps.
Автоматическое завершение рабочих элементов при выполнении запросов на включение внесенных изменений
Стало проще поддерживать актуальное состояние всех элементов при связывании рабочих элементов с запросами на вытягивание. Теперь при завершении запроса на вытягивание вы можете автоматически завершить связанные рабочие элементы после успешного объединения запроса (рис. 29). Если вы используете политики и настроили автозавершение запросов на вытягивание, вам также доступна эта функция. Вам больше не нужно возвращаться к рабочим элементам, чтобы изменить их состояние после завершения запроса. Это будет сделано автоматически.
Сброс голосов при отправке или новой итерации
Команды, которым требуется более строгий рабочий процесс утверждения в запросах на вытягивание, теперь могут использовать сброс голосов при отправке новых изменений (рис. 30). Новый параметр представляет собой один из вариантов политики Требовать минимальное число рецензентов.
Если этот режим задан, все голоса всех рецензентов будут сбрасываться каждый раз, когда изменяется исходная ветвь запроса на включение внесенных изменений. Благодаря этому параметру на временной шкале запроса на вытягивание в момент сброса голосов будет создаваться запись (рис. 31).
Фильтрация дерева запросов на включение внесенных изменений по имени файла
Найти конкретный файл в запросе на включение внесенных изменений теперь стало гораздо проще. Новое поле фильтра в представлении Файлы позволяет пользователям фильтровать список файлов в представлении в виде дерева (рис. 32).
Фильтр выполняет сопоставление по любой части пути к файлам в запросе на вытягивание, позволяя вам выполнять поиск по именам папок, неполным путям, именам файлов и расширениям (рис. 33).
Дополнительные параметры фильтрации комментариев к запросу на включение внесенных изменений
Комментарии в обзоре запроса на вытягивание и в представлении файлов теперь имеют одинаковые параметры (рис. 34). Также можно применить фильтр для просмотра только тех обсуждений, в которых вы участвовали.
Просмотр различий с исходным вариантом для комментариев к коду в сведениях о запросе на включение внесенных изменений
Иногда бывает трудно понять смысл комментария к запросу на вытягивание после изменения кода, на который он ссылается, особенно когда запрошенное изменение уже внесено (рис. 35).
В этом случае теперь отображается значок с номером изменения. Вы можете щелкнуть его и увидеть, как выглядел код на момент создания комментария (рис. 36).
Свертываемые комментарии к запросу на включение внесенных изменений
Проверка кода — это важнейшая часть работы с запросом на вытягивание, поэтому мы добавили новые функции, помогающие рецензентам сосредоточить внимание на коде. Рецензенты кода могут легко скрывать комментарии, чтобы они не мешали при просмотре кода в первый раз (рис. 37).
Функция скрытия комментариев (рис. 38) скрывает их из представления в виде дерева и сворачивает цепочки комментариев в представлении файлов:
Чтобы развернуть свернутые комментарии, щелкните значок в поле. Чтобы снова свернуть их, щелкните значок еще раз. Подсказки (рис. 39) позволяют легко посмотреть комментарий, не просматривая всю цепочку.
Списки задач в описаниях и комментариях к запросу на включение внесенных изменений
При подготовке запроса на включение внесенных изменений или создании комментариев у вас, как правило, есть короткий список аспектов, которые требуется отслеживать, но в конце концов приходится редактировать текст или добавлять несколько комментариев. Упрощенные списки задач — это отличный способ отслеживания хода выполнения для списка задач в качестве автора или рецензента запроса на вытягивание в описании или отдельном, объединенном комментарии. Щелкните панель инструментов Markdown, чтобы приступить к работе или применить формат к выделенному тексту (рис. 40).
После добавления списка задач (рис. 41) вы можете помечать элементы как завершенные, просто устанавливая флажки. Они выражаются и хранятся в комментарии как [ ] и [x] в файле Markdown. Дополнительные сведения см. в статье Markdown guidance (Руководство по Markdown).
Возможность поставить отметку "Нравится" для комментариев в запросах на включение внесенных изменений
Поддержите комментарий к запросу на вытягивание, нажав кнопку Нравится(рис. 42). Если вы наведете указатель мыши на эту кнопку, вы увидите список всех пользователей, которым понравился комментарий.
Улучшенный рабочий процесс при утверждении с предложениями
Использование функции автозавершения(рис. 43) с запросами на вытягивание — это отличный способ повысить эффективность работы, но оно не должно заменять активное обсуждение при проверке кода. Чтобы дополнительно повысить эффективность такого обсуждения, для запросов, для которых настроено автозавершение, теперь отображается вариант голосования утвердить с предложениями. Пользователь будет иметь возможность отменить автоматическое завершение, чтобы можно было прочитать его отзыв, или подтвердить его и разрешить автоматическое завершение запроса на включение внесенных изменений, когда будут выполнены все требования политик.
Поддержка фильтрации по пути для уведомлений Git
Вместо получения уведомлений для всех папок в репозитории теперь можно настроить получение уведомлений при создании участниками команды запросов на включение внесенных изменений или при отправке кода только в те папки, которые вас интересует. При создании настраиваемых подписок на уведомления по электронной почте для запросов на отправку или вытягивание вы увидите новый параметр, позволяющий фильтровать эти уведомления по пути к папке (рис. 44).
Обновлены шаблоны электронной почты для рабочих процессов запросов на вытягивание.
Мы обновили оповещения по электронной почте для запросов на вытягивание, сделав их более краткими, понятными и содержащими конкретные действия (рис. 45). Строка темы начинается с названия запроса и дополнительной информации, такой как имя репозитория, тогда как идентификатор указывается в конце. Имя автора было добавлено в тему, чтобы упростить применение правил и фильтров, основанных на имени пользователя, создавшего запрос.
Шаблон текста писем с оповещениями также обновлен: сначала кратко сообщается о том, почему отправлено оповещение, затем приводятся важные метаданные (название, имена ветвей и описания) и основная кнопка призыва к действию. Дополнительные сведения, такие как рецензенты, файлы и фиксации, содержатся в сообщении ниже.
Для большинства оповещений призывом к действию (рис. 46) будет предложение просмотреть запрос на вытягивание в Интернете. Тем не менее при получении уведомления о конкретном комментарии призывом к действию будет прямая ссылка на этот комментарий, позволяющая быстро найти код и предыдущее обсуждение для определения контекста.
Обновленные шаблоны электронной почты для push-уведомлений
Push-уведомления были обновлены в соответствии с новыми шаблонами электронной почты, которые стали более понятными, краткими и полезными в практическом плане (рис. 47). Строка темы позволяет легко различать сообщения об отправке и определять ветвь, репозиторий и автора. В ней также указывается общее число фиксаций, включенных в отправку. Кроме того, благодаря этим изменениям стало проще создавать правила и фильтры для управления уведомлениями по электронной почте.
Текст сообщения согласован с другими сообщениями. В нем указывается, по какой причине было отправлено сообщение, кто инициировал действие и что именно произошло. В оповещения об отправке включаются сведения о репозитории, ветви, файлах и фиксациях, благодаря которым получатели могут оценить объем изменений. Основной призыв к действию в случае push-уведомлений — Просмотреть push-уведомление. При выполнении этого действия открывается представление инициированного push-уведомления.
Вики-сайт
Все проекты теперь поддерживают собственные вики-сайты (рис. 48). Теперь вы можете создавать страницы, которые помогут участникам вашей команды получить представление о проекте, использовать его и участвовать в нем.
Ниже перечислены некоторые основные функции новых вики-сайтов.
- Упрощенный интерфейс редактирования с помощью синтаксиса Markdown.
- На новой странице можно указать название и добавить содержимое. (Рис. 49)
- Поддержка HTML-тегов в Markdown (рис. 50).
- Удобное изменение размеров изображения в папке Markdown (рис. 51).
- Многофункциональная панель управления страницами, которая позволяет менять их порядок, переподчинять страницы и управлять ими.
- Возможность фильтрации страниц по названию для больших вики-сайтов (рис. 52).
- Обновление вики-страниц в автономном режиме для опытных пользователей.
Совет
Дополнительные сведения о начале работы с вики-сайтом.
Чем дольше вы используете вики-сайт, тем больше вероятность сохранения нежелательных изменений. Теперь вы можете вернуть вики-страницу к предыдущей редакции. Для этого перейдите к сведениям о редакции и нажмите кнопку Отменить изменения(рис. 53).
Создание вики-страницы по неработающей ссылке
Во время создания вики-страницы содержание включало несуществующие ссылки (рис. 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.
Теперь вы можете скрывать удаленные версии пакетов (рис. 56) от всех пользователей веб-канала (больше никаких зачеркнутых пакетов).
Любое действие, которое можно было выполнить на странице сведений о пакете, теперь можно выполнить из контекстного меню в списке пакетов.
Список пакетов содержит новый столбец Последняя принудительная отправка(рис. 57) с удобными для восприятия датами, позволяющими легко найти недавно обновленные пакеты.
Пакеты Maven
Мы реализовали поддержку размещения артефактов Maven в TFS 2018 (рис. 58). Артефакты Maven позволяют разработчикам Java совместно использовать код и компоненты без лишних усилий. Ознакомьтесь с руководством по началу работы, в котором описано предоставление совместного доступа к артефактам Maven с помощью управления пакетами.
Новая унифицированная задача NuGet
Мы объединили задачи Восстановление NuGet, Упаковщик NuGet и Издатель NuGet в одну задачу сборки NuGet, чтобы обеспечить дополнительное согласование с остальной библиотекой задач сборки; новая задача использует NuGet 4.0.0 по умолчанию. Соответственно, старые задачи признаны нерекомендуемыми, и мы советуем вам перейти на новую задачу NuGet в любое удобное время. Это изменение совпадает с волной улучшений, описанных ниже. Доступ к ним можно будет получить только с помощью объединенной задачи.
В рамках этого проекта мы также выпустили новую задачу Установщик NuGet, которая управляет версией NuGet, доступной по ПУТИ и используемой новой задачей NuGet. Таким образом, чтобы использовать новейшую версию NuGet, просто добавьте задачу Программа установки средства NuGet в начале сборки (рис. 59).
Совет
См. дополнительные сведения об использовании в вашей сборке новейших версий 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 поддерживает каналы с проверкой подлинности и веб-проекты
В следующей основной версии задачи dotnet (2.x) представлены решения для многих запросов из ваших отзывов и устранен ряд ошибок, которые мы отслеживали на протяжении некоторого времени. Это включает следующее:
- Во-первых, задача dotnet теперь поддерживает источники пакетов с проверкой подлинности, такие как управление пакетами, поэтому вам больше не требуется использовать задачу NuGet для восстановления пакетов из частных источников пакетов.
- Поведение поля Путь к проекту изменилось в версии 2.0. В предыдущих версиях задачи, если не удавалось найти файл проекта, соответствующий указанному шаблону, задача записывала в журнал предупреждение, а затем успешно выполнялась. В таких случаях иногда может быть сложно понять, почему сборка выполнена успешно при этом зависимости не восстановлены. Теперь задача завершается ошибкой, если не удается найти файлы проектов, соответствующие указанному шаблону. Это согласуется с поведением других задач и упрощает понимание и использование.
- В предыдущих версиях команды публикации задачи задача изменяла выходной путь, помещая все файлы в папку, которой присваивалось имя, соответствующее имени файла проекта, даже в том случае, если был передан явный выходной путь. Это затрудняло создание цепочки команд. Теперь вы можете контролировать выходной путь к файлу.
Мы также выпустили новую задачу Установщик dotnet, которая управляет версией dotnet, доступной по ПУТИ и используемой новой задачей dotnet. Таким образом, чтобы использовать более новую версию dotnet, просто добавьте задачу Установщик dotnet в начало сборки.
Работа вне учетной записи или коллекции
Теперь стало проще работать с веб-каналами (рис. 61) за пределами вашего сервера TFS или учетной записи VSTS, будь то каналы системы управления пакетами в других учетных записях VSTS или серверах TFS или каналы, не относящиеся к управлению пакетами, такие как NuGet.org/npmjs.com, Artifactory или MyGet (рис. 60). Выделенные типы конечной точки службы для NuGet и npm упрощают ввод правильных учетных данных и позволяют задаче сборки эффективно работать в операциях загрузки и отправки пакетов.
Средство выбора веб-канала для каналов VSTS/TFS
Мы всегда рекомендуем выполнять возврат в файл конфигурации (например, NuGet.Config, NPMRC и т. д.), чтобы в репозитории источников создавалась запись о происхождения пакетов. Тем не менее мы знаем, что существуют ситуации, когда такое решение не является оптимальным. Поэтому мы добавили новый параметр Использовать пакеты из этого веб-канала VSTS или TFS, который позволяет выбрать веб-канал и автоматически создать файл конфигурации для этого шага сборки (рис. 62).
Сборка и выпуск
Сборки XAML
В Team Foundation Server 2015 была представлена кроссплатформенная система сборок. Сборки XAML не поддерживаются в TFS 2018 RTW или обновлении 1, но они повторно включены в TFS 2018 с обновлением 2. Мы рекомендуем выполнить перенос сборок XAML. Если вы еще не готовы к миграции и вам нужно по-прежнему использовать сборки XAML, перейдите на TFS 2018 с обновлением 2.
При обновлении до TFS 2018 RTW или обновления 1 происходит следующее.
Если в коллекции командных проектов есть данные сборок XAML, вы получите предупреждение об удалении компонентов сборки XAML.
Вы сможете просматривать завершенные сборки XAML, но не сможете добавлять новые сборки в очередь.
В TFS 2018 не появится новая версия контроллера или агента сборки XAML.
При обновлении до TFS 2018 с обновлением 2 происходит следующее.
Если в коллекции командных проектов есть данные сборок XAML, вы получите предупреждение о нерекомендуемых компонентах сборки XAML.
Чтобы изменить определения сборки XAML или поставить в очередь новые сборки XAML, потребуется использовать Visual Studio или Team Explorer 2017.
Если вам нужно создать агенты сборки XAML, установите их с помощью установщика агента сборки TFS 2015.
Совет
Объяснение планового устаревания сборки XAML см. в записи блога Развитие возможностей автоматизации сборки в TFS и Team Services.
Экспорт и импорт определений сборок
Определения сборок реализуются внутренним образом как JSON-файлы, чтобы можно было видеть сведения об изменениях в журнале файла. Функция клонирования и создания шаблонов на основе определений сборки уже доступна, но многим пользователям требовалась возможность копировать логику сборки CI и повторно использовать ее в других командных проектах. Этот запрос входил в 10 основных запросов на UserVoice.
Мы рады сообщить, что теперь это стало возможно (рис. 63 и рис. 64).
Расширения с шаблонами сборок
Шаблоны сборок позволяют создавать базовый план, чтобы приступить к работе с определением процесса сборки. Мы предлагаем большое число готовых шаблонов, и хотя можно было отправлять новые шаблоны в свою учетную запись, авторы расширений не могли включить новые шаблоны в расширение. Теперь вы можете включать шаблоны сборок в свои расширения. Например:
{ "id": "Template1",
"type": "ms.vss-build.template",
"targets": [ "ms.vss-build.templates" ],
"properties": { "name": "Template1" } }
Полный пример см. здесь: https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.
Совет
Эту возможность можно использовать, чтобы предлагать и совместно использовать один и тот же пользовательский шаблон во всех командных проектах.
Списание задачи в расширении
Теперь вы можете списать задачу в расширении. Для этого необходимо добавить следующую переменную в последнюю версию задачи.
"deprecated": true
При поиске нерекомендуемых задач (рис. 65) эти задачи отображаются в конце списка и группируются в сворачиваемом разделе, который по умолчанию уже свернут. Если определение уже использует устаревшую задачу, отображается значок устаревшей задачи, чтобы рекомендовать пользователям переключиться на заменяющую ее задачу.
Вы можете помочь пользователям получить сведения о заменяющей задаче, упомянув ее в описании задачи (рис. 66). Описание поможет пользователям, работающим с задачей, определить правильное направление из каталога задач и существующих определений сборки или выпуска.
Опубликованные разделы сборки могут управлять видимостью сборки
Ранее при использовании расширения, которое включало задачи сборки и разделы сводки сборки, раздел сводки отображался, даже если вы не использовали задачу в этой сборке. Теперь можно настроить скрытие или отображение этого раздела на странице сводки сборки, добавив следующую строку в код расширения и задав для нее значение true или false.
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);
Просмотрите примеры в репозитории Майкрософт vsts-extension-samples.
Поддержка групп переменных
Группы переменных были доступны в определениях выпуска, а теперь их можно использовать и в определениях сборок. Дополнительные сведения о создании группы переменных. Эта возможность разработана и получила высокий приоритет на основе соответствующих предложений по переменным сборки и выпуска уровня проекта и группам переменных в определениях сборки.
Работа с защищенными файлами, такими как сертификаты Apple
Мы добавили библиотеку защищенных файлов общего назначения (рис. 67).
Библиотеку защищенных файлов можно использовать для хранения таких файлов, как сертификаты для подписи, профили подготовки Apple, файлы хранилища ключей Android и ключи SSH, на сервере без необходимости их фиксации в исходном репозитории.
Содержимое защищенных файлов шифруется и может использоваться только во время процессов сборки или выпуска путем ссылки на них из задачи. Защищенные файлы доступны в нескольких определениях сборки и выпуска в командном проекте, в соответствии с параметрами безопасности. Защищенные файлы следуют модели безопасности библиотеки.
Мы также добавили некоторые задачи Apple, использующие эту новую функцию:
Приостановка определений сборки
Теперь можно приостановить или отключить определения сборки. Если вы планируете вносить изменения в определение сборки и хотите избежать постановки новых сборок в очередь, пока работа не будет завершена, просто отключите определение сборки. Аналогичным образом, если вы планируете обновлять компьютеры агентов, то можно приостановить определение сборки. При этом VSTS будет по-прежнему принимать новые запросы на сборку, но они будут помещаться в очередь и не будут выполняться, пока определение не будет возобновлено.
Поддержка проверок входных данных задач
При вводе параметров в задачах определения сборки иногда могут допускаться ошибки. С помощью проверки входных данных задачи ее авторы могут обеспечить правильность указываемых значений. Выражения проверки имеют стандартный синтаксис выражений, используемый для условий задачи. Помимо общих функций, поддерживаемых условиями задачи, в нем могут применяться любые другие поддерживаемые функции, в том числе URL-адрес, IPV4, адрес электронной почты, диапазон номеров, sha1, длина или совпадение.
Совет
Дополнительные сведения о назначении и использовании проверок см. на странице репозитория vsts-tasks.
Новый редактор определений выпуска
Продолжая проект по обновлению среды работы со сборками и выпусками, мы обновили редактор определений выпуска, чтобы сделать его более понятным, исправили некоторые проблемы, а также добавили новые возможности. Одной из наиболее эффективных функций нового редактора является визуализация хода развертывания в ваших окружениях. Кроме того, утверждения, свойства среды и параметры развертывания теперь отображаются в контексте, и их можно легко настроить.
Визуализация конвейера
Конвейер (рис. 68) в редакторе предоставляет графическое представление дальнейшего хода выполнения развертываний в выпуске. Артефакты используются выпуском и развертываются в средах. Макет и связывание сред отражают параметры триггера, заданные для каждой среды.
Пользовательский интерфейс конфигурации в контексте
Артефакты, триггеры выпуска, утверждения до и после развертывания, свойства среды и параметры развертывания теперь отображаются в контексте, и их можно легко настроить (рис. 69).
Начало работы с шаблонами развертывания
Все встроенные шаблоны развертывания обладают параметрами обработки, с помощью которых пользователи могут быстро начать работу, указав наиболее важные параметры. При этом им не требуется изучать задачи подробно (рис. 70).
Упрощенное управление переменными выпуска и среды
С помощью представления в виде списка можно быстро добавлять переменные выпуска и среды, а с помощью представления в виде сетки — сравнивать переменные, относящиеся к разным областям, и изменять их. Кроме того, в обоих представлениях можно использовать фильтр и поиск по ключевым словам для управления рабочим набором переменных.
Улучшенный редактор задач и этапов
Все усовершенствования в новом редакторе определений сборок теперь также доступны в редакторе определений выпуска (рис. 72). Находить задачи и добавлять их можно с помощью кнопки Добавить или путем перетаскивания. С помощью перетаскивания можно клонировать задачи или изменять их порядок.
Группы переменных, хранение и вкладка "Параметры"
Теперь можно связать или отменить связь с группами переменных (рис. 73), задать политику хранения для отдельных сред и изменить параметры уровня определения выпуска, такие как формат номера выпуска на вкладке "Параметры ". Вы также можете сохранить среду в качестве шаблона развертывания, задать разрешения на уровне среды и этапы повторного заказа на вкладке "Задачи ".
Операции уровня среды можно сохранять как шаблон и использовать их для задания параметров безопасности (рис. 74).
Развертывание виртуальных машин с помощью групп развертывания
Компонент Release Management теперь поддерживает надежные, готовые функции развертывания нескольких виртуальных машин. Теперь вы можете управлять развертываниями на нескольких компьютерах и выполнять последовательные обновления с гарантированно высоким уровнем доступности приложений.
Функция развертывания на основе агентов использует те же агенты сборки и развертывания. В отличие от текущего подхода, когда агенты сборки и развертывания устанавливаются для набора прокси-серверов в пуле агентов и развертывания передаются на удаленные целевые серверы, вы можете установить агент на каждом из целевых серверов непосредственно и передавать последовательные развертывания на эти серверы. Вы можете использовать полный каталог задач на целевых компьютерах.
Группа развертывания (рис. 75) представляет собой логическую группу целевых объектов (компьютеров), на каждом из которых установлены агенты. Группы развертывания представляют физические среды, такие как разработка с одним полем, многофакторное управление безопасностью и ферма компьютеров для UAT/Prod. Они также указывают контекст безопасности для физических сред.
Их можно использовать для любой виртуальной машины, с которой вы регистрируете агента. Кроме того, мы упростили регистрацию в Azure с поддержкой расширения "Виртуальная машина Azure", которое автоматически устанавливает агент при развертывании виртуальной машины. Теги для виртуальной машины Azure автоматически наследуются при регистрации.
Создав группу развертывания, вы можете просто задать необходимые для выполнения в ней операции (рис. 76). Вы можете контролировать компоненты, выполняемые на тех или иных виртуальных машинах, с помощью тегов и управлять скоростью развертывания.
При запуске развертывания ход выполнения для всей целевой группы компьютеров отражается в журналах (рис. 77).
Эта функция теперь является неотъемлемой частью системы управления выпусками. Дополнительные лицензии не требуются.
Улучшенный пользовательский интерфейс групп развертывания
В продолжение усилий по обновлению среды работы со сборками и выпусками мы обновили страницы групп развертывания, чтобы сделать их более понятными (рис. 78). На целевой странице можно просмотреть сведения о работоспособности целевых объектов в группе развертывания. Кроме того, можно управлять безопасностью отдельной группы развертывания или задавать разрешения по умолчанию для групп развертывания.
Для целевого объекта в группе развертывания можно просмотреть сводку, последние развертывания и возможности целевого объекта (рис. 79). Вы можете задавать теги для целевого объекта и управлять тем, что выполняется в каждом целевом объекте. В ближайших выпусках будет добавлена поддержка фильтров для групп развертывания.
Ссылки группы задач
Группы задач позволяют определить набор задач, которые можно добавить в определения сборок и выпусков (рис. 80). Это удобно, если необходимо использовать одинаковые группы задач в нескольких сборках или выпусках. Для эффективного отслеживания объектов-получателей группы задач теперь вы можете просматривать определения сборок, определения выпусков и группы задач, которые ссылаются на вашу группу задач (рис. 79).
При попытке удалить группу задач, на которую все еще есть ссылки, выводится предупреждение и ссылка на эту страницу.
Управление версиями группы задач
Внесение изменений в группы задач может быть рискованным, так как изменение вступает в силу для всех определений, которые используют эту группу задач. Благодаря функции управления версиями группы задач теперь можно создавать черновики и просматривать версии группы задач, сохраняя наиболее стабильные версии для важнейших определений, пока не будет готова новая версия. Создав несколько черновиков и итераций, можно опубликовать стабильную версию, кроме того, во время публикации, если изменения являются существенными, можно опубликовать группу задач как предварительную версию (новый основной номер версии). Вы также можете опубликовать ее непосредственно как обновленную стабильную версию (рис. 81).
Когда будет доступна новая основная (или предварительная) версия этой группы задач, редактор определений проинформирует вас о наличии новой версии. Если эта основная версия находится в режиме предварительной версии, также будет выведено сообщение "Попробуйте". Когда группа задач переходит из состояния предварительной версии, использующие ее определения автоматически обновляются, продвигаясь в соответствии с основным каналом (рис. 82).
Импорт и экспорт группы задач
Хотя группы задач можно было повторно использовать в проекте, процесс повторного создания группы задач для нескольких проектов и учетных записей представлял сложности. Функции импорта и экспорта группы задач (рис. 83) теперь, как и для определений выпуска, поддерживают экспорт в виде файлов JSON и импорт туда, куда вам нужно. Мы также включили поддержку вложенных групп задач, которые разворачиваются при экспорте.
Поддержка нескольких конфигураций в задачах на стороне сервера (без агента)
Указав множители переменных для задач на стороне сервера (без агента, рис. 84), теперь вы можете запускать в ходе этапа один набор задач для множества конфигураций, которые работают параллельно.
Поддержка переменных в задаче "Вмешательство вручную"
Задача Вмешательство вручную(рис. 85) теперь поддерживает переменные в тексте инструкций, который показывается пользователям при выполнении задачи в точке, где пользователь может возобновить выполнение процесса выпуска или отклонить его. В нее можно включать любые переменные, определенные и доступные в выпуске, и их значения будут использоваться в уведомлениях и отправляемых пользователям сообщениях электронной почты (рис. 86).
Управление выпусками в среде в зависимости от исходной ветви
Определение выпуска можно настроить для запуска развертывания автоматически при создании нового выпуска, как правило, после успешной сборки источника. Тем не менее, вам может потребоваться развертывать только сборки из определенных ветвей источника, а не при успешном завершении любой сборки.
Например, может потребоваться, чтобы все сборки развертывались в средах разработки и тестирования и только некоторые из них — в рабочей среде. В прежних версиях нужно было поддерживать два конвейера выпуска для этой цели: один для сред разработки и тестирования, а другой — для рабочей среды.
Release Management теперь поддерживает использование фильтров артефактов для каждой среды. Это означает, что можно указать выпуски, которые будут развернуты в каждой среде при соблюдении условий триггера развертывания (таких как успешная сборка или создание выпуска). В разделе Триггер диалогового окна Условия развертывания среды (рис. 87) выберите условия артефакта, такие как исходная ветвь и теги для сборок, которые будут активировать новое развертывание для этой среды.
Кроме того, страница сводки по выпуску(рис. 88) теперь содержит всплывающую подсказку, которая указывает причину всех "незапущенных" развертываний и предположение о способе и времени запуска развертывания.
Триггеры выпуска для репозиториев Git как источник артефакта
Release Management теперь поддерживает настройку триггера непрерывного развертывания (рис. 89) для репозиториев Git, связанных с определением выпуска в любом из командных проектов одной учетной записи. Это позволяет автоматически активировать выпуск при создании новой фиксации в репозитории. Можно также указать ветвь в репозитории Git, для которой фиксации будут запускать выпуск.
Триггеры выпуска: непрерывное развертывание для изменений, отправленных в репозиторий Git
Компонент Release Management всегда предоставлял возможность настроить непрерывное развертывание после завершения сборки. Но теперь непрерывное развертывание можно также настроить для команды Git Push. Это означает, что можно связать репозитории Git GitHub и Team Foundation в качестве источников артефактов для определения выпуска, а затем автоматически активировать выпуски для приложений, таких как Node.JS и PHP, которые не создаются на основе сборки и не требуют действия сборки для непрерывного развертывания.
Фильтры ветвей в триггерах среды
В новом редакторе определений выпуска можно указывать условия артефактов для определенной среды. С помощью этих условий можно более детально управлять тем, какие артефакты должны развертываться в определенной среде. Например, в рабочей среде может быть необходимо развертывать только сборки, созданные в главной ветви. Этот фильтр нужно задать для всех артефактов, которые, по вашему мнению, должны отвечать условию.
Вы также можете добавить несколько фильтров для каждого артефакта, связанного с определением выпуска (рис. 90). Развертывание в среде инициируется, только если соблюдены все условия артефактов.
Усовершенствования для задач на стороне сервера
Мы внесли несколько улучшений в задачи на стороне сервера (задачи, которые выполняются на этапе сервера).
Мы добавили новую задачу, которая вызывает любой универсальный интерфейс REST API с HTTP (рис. 91) в составе автоматического конвейера. Например, ее можно использовать для вызова определенной обработки с помощью функции Azure и ожидания ее завершения.
Мы также добавили раздел Параметры управления (рис. 92) для всех задач на стороне сервера. Поведение задачи теперь включает настройку параметров Включено, Продолжать при ошибке, Всегда запускать и Время ожидания.
Значок состояния выпуска в центре кода
До сих пор, если вы хотели узнать, развернута ли фиксация в рабочей среде клиента, сначала необходимо было определить, какая сборка использует фиксацию, а затем проверить все среды выпусков, в которых развернута эта сборка. Теперь этот процесс стал гораздо проще благодаря интеграции состояния развертывания в значок состояния центра кода, который отображает список сред, в которых развертывается код. При каждом развертывании состояние отправляется в последнюю фиксацию, которая была частью развертывания. Если фиксация развертывается в нескольких определениях выпуска (с несколькими средами), каждый выпуск содержит на значке запись и для каждой среды отображается состояние (рис. 93). Это повышает эффективность отслеживания фиксаций кода в развертываниях.
По умолчанию при создании определения выпуска состояние развертывания публикуется для всех сред. Но вы можете сами выбрать среды, состояние развертывания которых должно отображаться на значке состояния, например только рабочие среды (рис. 94).
Усовершенствования в меню определения сборки при добавлении артефактов
При добавлении артефактов сборки в определение выпуска теперь вы можете просматривать определения со сведениями об организации папок, что упрощает выбор нужного определения (рис. 95). Это позволяет легко различать определения сборки с одним именем, но в разных папках.
Список определений фильтруется: выводятся те определения, которые содержат условие фильтра.
Возврат определения выпуска к старой версии
До сих пор при обновлении определения выпуска нельзя было вернуться к предыдущей версии напрямую. Единственным способом было изучение журнала определения выпуска для поиска разницы изменений и последующее изменение определения выпуска вручную. Теперь с помощью функции Отменить определение(рис. 96) вы можете выбрать и восстановить любую предыдущую версию определения выпуска на вкладке Журнал.
Персонализированные уведомления для выпусков
Уведомления о выпусках теперь включены в интерфейс для настройки параметров уведомлений Visual Studio Team Services. Те, кто управляет выпусками, теперь автоматически оповещаются об ожидающих выполнения действиях (утверждениях или вмешательствах вручную) и важных сбоях развертывания. Вы можете отключить эти уведомления, перейдя к параметрам Уведомление в меню профиля и отключив подписки на выпуски. Кроме того, можно подписаться на дополнительные уведомления, создав пользовательские подписки. Администраторы могут управлять подписками для команд и групп на странице параметров Уведомление в разделах Команда и Учетная запись.
Авторам определения выпуска больше не нужно вручную отправлять сообщения электронной почты для утверждения и завершения развертывания.
Это особенно полезно в случае с большими организациями, в которых с выпусками связано много заинтересованных лиц и где нужно уведомлять других лиц, помимо утверждающего, создателя выпуска и владельца среды (рис. 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 (Выполнение операций управления лабораторией в выпуске и сборке).
Автоматическое тестирование
- Больше не поддерживается:
- Рабочие процессы автоматического тестирования, которые зависят от контроллеров тестирования и лабораторных сред, такие как рабочий процесс "сборка-развертывание-тестирование" XAML или запуск автоматических тестов из плана тестирования с помощью MTM, больше не поддерживаются.
- Рекомендуемые варианты:
Тестирование вручную
- Все сценарии тестирования вручную по-прежнему полностью поддерживаются. Хотя ручные тесты можно выполнять с помощью MTM в TFS 2018, лабораторные среды нельзя использовать для выполнения ручных тестов.
- Для всех сценариев тестирования вручную мы настоятельно рекомендуем использовать центр тестирования в веб-интерфейсе TFS.
Улучшения прослеживаемости произвольного тестирования для ссылок на рабочие элементы, итераций и путей к областям
Основываясь на отзывах, которые мы получили от команд, использующих произвольное тестирование, мы улучшаем прослеживаемость ссылок при регистрации ошибок, задач и тестовых случаев из расширения "Тестирование и обратная связь". Ошибки и задачи, созданные при просмотре требований, теперь будут создаваться с использованием того же пути к области и итерации, что и в требовании, вместо значений команды по умолчанию. Тестовые случаи, созданные при просмотре требований, теперь будут связываться с помощью ссылки Тесты <-> Тест выполнил, а не ссылки Родительский объект <-> Дочерний объект. Это позволит автоматически добавлять связанные тестовые случаи в наборы тестов на основе требований. И, наконец, рабочие элементы, созданные не при просмотре какого-либо требования, регистрируются в итерации команды по умолчанию вместо текущей итерации, чтобы новые рабочие элементы не поступали в текущую итерацию после завершения планирования спринта.
Фильтры для рабочих элементов тестового случая в планах тестирования и наборах тестов в центре тестирования
Помимо фильтров в полях Тест, таких как Результат, Конфигурация и Тест-инженер, теперь доступна фильтрация по полям рабочих элементов в тестовых случаях, таких как Название, Состояние и Кому назначено (рис. 98).
Диаграммы тренда тестирования для сред выпуска и тестовых запусков
Мы добавили поддержку сред выпуска в мини-приложение Тренд результатов тестирования(рис. 99), чтобы вы могли отслеживать состояние сред тестирования на панелях мониторинга VSTS. Аналогично функциям, доступным для результатов тестирования в разделе Сборка, теперь можно создавать диаграммы тренда, показывающие долю пройденных тестов, общее число тестов, число пройденных или непройденных тестов и длительность теста для сред выпуска. Кроме того, диаграммы можно фильтровать по конкретному тестовому запуску в среде, используя фильтр по названию Тестовый запуск.
Поддержка форматирования разметки Markdown для комментариев "Тестовый запуск" и "Результат теста"
Мы добавили поддержку форматирования комментариев Тестовый запуск и Результат теста с синтаксисом Markdown. Эту функцию можно использовать, чтобы создать форматированный текст или быстрые ссылки на URL-адреса в комментариях. Комментарии Результат теста можно изменить на странице Сводка результатов с помощью комментариев Анализ обновления и Тестовый запуск на странице Сводка запуска с помощью кнопки Обновить комментарии в центре тестирования.
Добавление ссылки на существующую ошибку для непройденного теста
Во время анализа результатов тестирования на сводной странице Сборка или Выпуск, а также в центре тестирования теперь можно связать существующую ошибку с непройденным тестом. Это удобно в тех случаях, когда сбой теста происходит по известной причине, ошибка для которой уже зарегистрирована.
Отправка вложений к тестовым запускам и результатам тестов
В тестовые запуски или результаты тестов теперь в качестве дополнительной информации можно вкладывать файлы, например снимки экрана и файлы журналов. До сих пор эта возможность была доступна только в клиенте Microsoft Test Manager (MTM), из-за чего приходилось переключаться между центром тестирования в Visual Studio Team Services или Team Foundation Server и клиентом MTM.
Пакетная обработка тестов
В области управления сборками и выпусками для задачи теста Visual Studio доступны параметры, с помощью которых можно управлять тем, как должны группироваться (объединяться в пакеты) тесты для эффективного выполнения. Тесты можно группировать двумя способами:
- в соответствии с числом тестов и агентов, участвующих в запуске; при этом тесты просто объединяются в несколько пакетов определенного размера;
- в соответствии с временем предыдущего выполнения тестов; при этом пакеты тестов формируются так, чтобы каждый пакет имел приблизительно одинаковое время выполнения (рис. 100). Быстро и долго выполняющиеся тесты объединяются в разные пакеты. Чтобы свести общее время тестирования к минимуму, этот параметр можно применять в сочетании с настройкой, подразумевающей этап использования нескольких агентов.
Выполнение веб-тестов с помощью задачи VSTest
С помощью задачи теста Visual Studio веб-тесты, также называемые веб-тестами производительности, теперь можно выполнять в рамках конвейера непрерывной интеграции и непрерывного развертывания. Для выполнения веб-тестов их можно указать во входных данных сборки задачи. Любой рабочий элемент тестового случая, связанная автоматизация которого связана с веб-тестом, можно также выполнить, выбрав в задаче план тестирования или набор тестов (рис. 101).
Результаты веб-теста доступны в виде вложения в результаты теста (рис. 102). Их можно скачать для автономного анализа в Visual Studio.
Эта возможность зависит от изменений в платформе тестирования Visual Studio и требует установки Visual Studio 2017 с обновлением 4 в агенте сборки или выпуска. Веб-тесты нельзя выполнять с помощью предыдущих версий Visual Studio.
Аналогичным образом, веб-тесты можно выполнять с помощью задачи запуска функционального теста. Эта возможность зависит от изменений в агенте тестирования, который будет доступен в составе Visual Studio 2017 с обновлением 5.
Совет
Пример использования этой возможности с нагрузочным тестированием см. в кратком руководстве по нагрузочному тестированию приложения в облаке с помощью Visual Studio и Visual Studio Team Services.
Мини-приложение диаграмм для планов тестирования и наборов тестов
Ранее вы могли создавать диаграммы для планов тестирования и наборов тестов в центре тестирования, а затем закреплять их на панели мониторинга. Мы добавили мини-приложение, которое позволяет создавать диаграммы для планов тестирования и наборов тестов из каталога мини-приложений на панели мониторинга. Вы можете создавать диаграммы, отражающие состояние разработки или выполнения тестов. Кроме того, с помощью мини-приложения можно создавать более крупные диаграммы, содержащие больший объем данных рис. 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.
Как обстоят дела?
Мы будем рады узнать ваше мнение! Сообщить о проблеме и отслеживать ее можно с помощью портала сообщества разработчиков, а получить совет можно на сайте Stack Overflow.