Заметки о выпуске Azure DevOps Server 2022 с обновлением 2
| Сообщество разработчиков Системные требования и условия лицензионного | соглашения | devOps блог | SHA-256 | |
В этой статье вы найдете сведения о новом выпуске для Azure DevOps Server.
Дополнительные сведения об установке или обновлении развертывания Azure DevOps Server см. в статье "Требования к серверу Azure DevOps".
Чтобы скачать продукты Azure DevOps Server, перейдите на страницу загрузки azure DevOps Server.
Прямое обновление до Azure DevOps Server 2022 с обновлением 2 поддерживается из Azure DevOps Server 2019 или Team Foundation Server 2015 или более поздней версии. Если развертывание TFS находится в TFS 2013 или более ранней версии, перед обновлением до Azure DevOps Server 2022 необходимо выполнить некоторые промежуточные действия. Дополнительные сведения см. на странице "Установка".
Дата выпуска обновления 2 для Azure DevOps Server 2022 с обновлением 2: 12 ноября 2024 г.
| Файлы | Хэш SHA-256 |
|---|---|
| devops2022.2patch2.exe | 70930BE091607B490890A488C250DAB6C2087F7F610CC695C9C632C679A491D23 |
Мы выпустили исправление 2 для Azure DevOps Server 2022 с обновлением 2, чтобы включить обновление до уязвимой зависимости.
Дата выпуска Azure DevOps Server 2022.2 RTW: 9 июля 2024 г.
Сводка о новых возможностях Azure DevOps Server 2022.2 RTW
Примечание.
Мы повторно выпустили Azure DevOps Server 2022.2, чтобы устранить проблему с загрузкой имен Teams. Проблема была сообщена в записи блога Azure DevOps Server 2022.2 RTW. Если вы установили версию Azure DevOps Server 2022.2, выпущенную 9 июля, можно установить исправление 1 для Azure DevOps Server 2022.2 , чтобы устранить эту проблему. Исправление 1 не требуется, если вы устанавливаете Azure DevOps Server 2022.2 впервые после обновления ссылок загрузки, чтобы включить исправление.
Azure DevOps Server 2022.2 RTW — это свертка исправлений ошибок. Он включает все функции в ранее выпущенном rc-кандидате Azure DevOps Server 2022.2. Вы можете напрямую установить Azure DevOps Server 2022.2 или обновить с Azure DevOps Server 2020, 2019 или Team Foundation Server 2015 или более поздней версии. В этом выпуске устранены следующие проблемы и уязвимости:
- CVE-2024-35266: уязвимость spoofing сервера Azure DevOps
- CVE-2024-35267: уязвимость spoofing сервера Azure DevOps
- Сообщество разработчиков запрос обратной связи: версия агента не обновляется после обновления до Azure DevOps Server 2022.1 и использования агента обновления в конфигурации пула агентов
- Сообщество разработчиков запрос обратной связи: проблема с загрузкой страницы конфигурации команды
- Сообщество разработчиков запрос обратной связи: исправление неправильной обработки даты в уведомлении по электронной почте pr для определенных региональных форматов
Дата выпуска rc 2 для Azure DevOps Server 2022 с обновлением 2: 7 мая 2024 г.
Rc-кандидат Azure DevOps Server 2022.2 включает множество новых функций. Вот некоторые из них:
- Ограничения для путей области и итерации
- Обход утверждений и проверок в конвейерах
- Улучшенная проверка YAML
- Поддержка azure Artifacts для cargo Crates
- Новый интерфейс каталога панели мониторинга
- Быстрое копирование и импорт с помощью тестового плана или идентификатора набора
Вы также можете перейти к отдельным разделам, чтобы просмотреть все новые возможности для каждой службы:
Общие
Публикация задачи "Результаты теста"
Задача "Опубликовать результаты теста" теперь поддерживает вложения тестового запуска для формата отчета JUnit.
Новая версия пакета SDK для веб-расширения Azure DevOps
В этом обновлении мы выпускаем новую версию пакета SDK для веб-расширений Azure DevOps. Клиентский пакет SDK позволяет веб-расширениям взаимодействовать с кадром узла. Его можно использовать для:
- Сообщите узлу, что расширение загружено или имеет ошибки
- Получение основных контекстных сведений о текущей странице (сведения о текущем пользователе, узле и расширении)
- Получение сведений о теме
- Получение маркера авторизации для использования в вызовах REST обратно в Azure DevOps
- Получение удаленных служб, предлагаемых фреймом узла
Полный справочник по API можно найти в документации по пакету sdk для azure-devops-extension-sdk. Эта новая версия обеспечивает поддержку следующих модулей:
Поддержка модулей ES: пакет SDK теперь поддерживает модули ES (ECMAScript) в дополнение к существующим модулям AMD (асинхронное определение модуля). Теперь пакет SDK можно импортировать с помощью синтаксиса модуля ES, который обеспечивает улучшения производительности и уменьшает размер приложения.
Обратная совместимость для модулей AMD: существующая поддержка модулей AMD остается нетронутой. Если проект использует модули AMD, вы можете продолжать использовать их, как и раньше, без каких-либо изменений.
Практическое руководство.
Для модулей ES можно импортировать наши модули с помощью инструкции импорта:
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
Если вы используете модули AMD, вы можете продолжать импортировать пакет SDK с помощью require функции:
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards
Ограничения для путей области и итерации
Ограничения играют важную роль в поддержании работоспособности и эффективности крупной глобальной службы. В этом выпуске мы введем жесткие ограничения в размере 10 000 на проект как для областей, так и для путей итерации. Перейдите на страницу "Отслеживание работы", "Процесс" и "Ограничения проекта", чтобы узнать больше о различных ограничениях в службе.
Элементы управления разработкой и развертыванием
Теперь мы удаляем элементы управления "Разработка" и (или) "Развертывание" из рабочего элемента в зависимости от того, как настроен проект. Например, можно настроить параметры проекта, чтобы отключить репозитории и (или) конвейеры.
При переходе к рабочему элементу соответствующие элементы управления разработки и развертывания будут скрыты из формы.
Если вы решите подключить репозиторий GitHub к Azure Boards, отобразится элемент управления разработки для репозиториев GitHub.
Repos
Новая политика "Ветвь" запрещает пользователям утверждать свои собственные изменения
Чтобы улучшить контроль над тем, что пользователь утверждает и соответствует более строгим нормативным или нормативным требованиям, мы предоставляем возможность предотвратить утверждение пользователем собственных изменений, если только явно не разрешено.
Пользователь с возможностью управления политиками ветви теперь может переключить только что добавленный параметр "Требовать по крайней мере одно утверждение для каждой итерации" в разделе "При отправке новых изменений". При выборе этого параметра требуется по крайней мере одно голосование за последнее изменение исходной ветви. Утверждение пользователя не учитывается в отношении предыдущей неутвержденной итерации, отправленной этим пользователем. В результате требуется дополнительное утверждение последней итерации другим пользователем.
На следующем рисунке показан запрос на вытягивание, созданный пользователем A и дополнительными 4 фиксациями (итерациями), сделанными для этого запроса на вытягивание пользователями B, C, A еще раз и C. После завершения второй итерации (фиксация, выполненная пользователем B), пользователь C одобрил это. В то время оно подразумевало утверждение первой фиксации пользователя A (когда был создан запрос на вытягивание) и вновь введенная политика будет успешно выполнена. После пятой итерации (последняя фиксация пользователя C) утверждение было сделано пользователем A. Это подразумеваемое утверждение для предыдущей фиксации, выполненной пользователем C, но не подразумевало утверждение второй фиксации, выполненной пользователем A в четвертой итерации. Чтобы сделать недавно введенную политику успешной, неутвержденные итерации четыре должны быть утверждены либо утверждением от пользователя B, C или любого другого пользователя, который не внес никаких изменений в запрос на вытягивание.
Примечание.
Существует известная проблема, из-за которой политики ветви будут принимать группу, настроенную как рецензент, как утверждение сущности. Предположим, что существует требуемое утверждение, сделанное любым пользователем группы G. User A является членом этой группы G. После того как пользователь A предоставляет утверждение, как показано на рисунке выше (после пятой итерации), утверждение Группы G утверждает изменение, выполненное пользователем A. Это не ожидается и будет разрешено в выпуске RTW.
Поддержка фильтров без больших двоичных объектов и без деревьев
Внимание
Эта функция отключена по умолчанию. Чтобы включить эту функцию, выполните следующий запрос в базе данных конфигурации:
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
Azure DevOps теперь поддерживает два дополнительных фильтра во время клонирования и извлечения. Ниже приведены следующие параметры: --filter=blob:none и --filter=tree:0 Первый вариант (клон без больших двоичных объектов) лучше всего используется для регулярной разработки, а второй вариант (клон без дерева) лучше подходит для тех случаев, когда вы отменяете клон после, например запуск сборки.
Отмена SSH-RSA
Azure Repos предоставляет два метода для доступа пользователей к репозиторию git в Azure Repos — HTTPS и SSH. Чтобы использовать SSH, необходимо создать пару ключей с помощью одного из поддерживаемых методов шифрования. В прошлом мы поддерживали только SSH-RSA, и мы попросили пользователей включить SSH-RSA здесь.
В этом обновлении мы объявляем об отмене SSH-RSA в качестве поддерживаемого метода шифрования для подключения к Azure Repos с помощью SSH. Дополнительные сведения см. в разделе "Окончание поддержки SSH-RSA" для записи блога Azure Repos .
Pipelines
Предотвращение непреднамеренных запусков конвейера
Сегодня, если конвейер YAML не указывает trigger раздел, он запускается для любых изменений, отправленных в его репозиторий. Это может привести к путанице в том, почему конвейер выполняется и приводит к множеству непреднамеренных запусков.
Мы добавили параметр коллекции проектов и конвейеров уровня проекта с именем Disable подразумеваемый триггер CI YAML, который позволяет изменить это поведение. Вы можете не активировать конвейеры, если их раздел триггера отсутствует.
Повторите этап, когда утверждения и проверка времени ожидания
Когда утверждения и проверка времени ожидания, этап, к которому они относятся, пропускается. Этапы, имеющие зависимость от пропущенного этапа, также пропускаются.
Теперь можно повторить этап, когда утверждения и проверка времени ожидания. Ранее это было возможно только при истечении времени ожидания утверждения.
Обход утверждений и проверок
Утверждения и проверки помогают защитить доступ к важным ресурсам, таким как подключения служб, репозитории или пулы агентов. Распространенным вариантом использования является использование утверждений и проверок при развертывании в рабочей среде, и вы хотите защитить подключение службы ARM.
Предположим, что вы добавили следующие проверки подключения к службе: утверждение, проверка рабочих часов и проверка функции Azure (для принудительной задержки между различными регионами).
Теперь представьте, что необходимо выполнить развертывание исправлений. Запуск конвейера не выполняется, но он не продолжается, он ожидает завершения большинства проверок. Вы не можете позволить себе ждать завершения утверждений и проверок.
В этом выпуске мы сделали возможным обойти выполняемые утверждения и проверки, чтобы вы могли завершить исправление.
Можно обойти выполнение утверждений, рабочих часов, вызов функции Azure и вызов проверок REST API.
Обход утверждения.
Обход проверки рабочих часов.
Обход проверки функции Azure. Обход проверки рабочих часов.
При обходе проверки его можно увидеть на панели проверок.
Можно обойти проверку только в том случае, если вы являетесь администратором ресурса, на котором были определены проверки.
Повторное выполнение проверок функций Azure
Представьте, что вы развертываете систему на нескольких этапах. Перед развертыванием второго этапа существует проверка утверждения и вызова функции Azure, которая запускает проверку sanity в уже развернутой части системы.
При проверке запроса на утверждение вы заметите, что проверка работоспособности выполнена два дня назад. В этом сценарии может быть известно о другом развертывании, которое повлияло на результат проверки работоспособности.
С помощью этого обновления можно повторно запустить функцию Azure и вызвать проверки REST API. Эта функция доступна только для проверок, которые успешно выполнены и не имеют повторных попыток.
Примечание.
Можно повторно выполнить проверку только в том случае, если вы являетесь администратором ресурса, на котором были определены проверки.
Поддержка корпоративного сервера GitHub в обязательной проверке шаблона
Шаблоны — это механизм безопасности, позволяющий управлять этапами, заданиями и этапами конвейеров в коллекции проектов.
Проверка шаблона "Требовать" позволяет принудительно применять конвейер из набора утвержденных шаблонов перед доступом к защищенному ресурсу, например к пулу агентов или подключению к службе.
Теперь вы можете указать шаблоны, расположенные в репозиториях GitHub Enterprise Server.
Роль администратора для всех сред
Среды в конвейерах YAML представляют вычислительный ресурс, в котором развертывается приложение, например кластер AKS или набор виртуальных машин. Они предоставляют средства управления безопасностью и возможность трассировки для развертываний.
Управление средами может быть довольно сложной задачей. Это связано с тем, что при создании среды пользователь, создающий его, автоматически становится единственным администратором. Например, если вы хотите управлять утверждениями и проверками всех сред в централизованном режиме, вам пришлось попросить каждого администратора среды добавить определенного пользователя или группы в качестве администратора, а затем использовать REST API для настройки проверок. Этот подход является емким, подверженным ошибкам и не масштабируется при добавлении новых сред.
В этом выпуске мы добавили роль администратора на уровне центра сред. Это обеспечивает синтаксический анализ сред с подключениями к службам или пулами агентов. Чтобы назначить роль администратора пользователю или группе, необходимо уже быть администратором среды или владельцем коллекции проектов.
Пользователь с этой ролью администратора может администрировать разрешения, управлять, просматривать и использовать любую среду. Это включает открытие сред для всех конвейеров.
При предоставлении роли администратора пользователей на уровне центра сред они становятся администраторами для всех существующих сред и для любых будущих сред.
Улучшенная проверка YAML
Чтобы проверить правильность синтаксиса YAML, можно использовать функцию проверки веб-редактора Azure Pipelines. Таким образом, важно, чтобы эта функция перехватыла как можно больше проблем YAML.
Проверка YAML теперь более тщательна, когда речь идет о выражениях.
При написании конвейеров YAML можно использовать функции для определения значений переменных.
Представьте, что вы определяете следующие переменные:
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
Переменная Patch определяется с помощью counter функции и других двух переменных. В приведенном выше коде YAML слово format имеет ошибка. Ранее эта ошибка не была обнаружена. Теперь функция проверки обнаружит это и обнаружит сообщение об ошибке.
Azure Pipelines обнаружит неправильные определения переменных на уровне конвейера или этапа или задания.
В конвейерах YAML можно пропустить выполнение этапа с помощью условий. Опечатки также могут отображаться здесь, как показано в следующем примере.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
Задача NuGetCommand выполняется только в том случае, если значение переменной Patch равно 0. Опять же, в условии есть опечатка, и функция проверки отобразит ее.
Azure Pipelines обнаружит неверные условия YAML, определенные на уровне конвейера или этапа или задания.
REST API для сред
Среда — это коллекция ресурсов, предназначенных для развертываний из конвейера. Среды предоставляют журнал развертывания, возможность трассировки рабочих элементов и фиксаций, а также механизмы управления доступом.
Мы знаем, что вы хотите создавать среды программным способом, поэтому мы опубликовали документацию по REST API.
Улучшения REST API утверждений
Мы улучшили поиск утверждений, назначенных пользователю, включив группы, к которым принадлежит пользователь в результатах поиска.
Теперь утверждения содержат сведения о запуске конвейера, к которому они относятся.
Например, следующий вызов https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending REST API GET возвращает
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Журналы конвейеров теперь содержат использование ресурсов
Журналы конвейера Azure теперь могут записывать метрики использования ресурсов, такие как память, использование ЦП и доступное место на диске. Журналы также включают ресурсы, используемые агентом конвейера и дочерними процессами, включая задачи, выполняемые в задании.
Если вы подозреваете, что задание конвейера может столкнуться с ограничениями ресурсов, включите подробные журналы для внедрения сведений об использовании ресурсов в журналы конвейера. Это работает на любом агенте, независимо от модели размещения.
Агент Azure Pipelines теперь поддерживает Alpine Linux
Агент конвейера версии 3.227 теперь поддерживает Alpine Linux версии 3.13 и выше. Alpine Linux — это популярный образ контейнера (базовый). Агент можно найти на странице выпусков . В версиях агента Alpine Linux есть префикс vsts-agent-linux-musl , например vsts-agent-linux-musl-x64-3.227.1.tar.gz.
Задачи Azure Pipelines используют узел 16
Задачи в конвейере выполняются с помощью средства выполнения с Node.js, используемыми в большинстве случаев. Задачи Azure Pipelines, использующие узел в качестве бегуна, теперь используют узел 16. Так как Node 16 является первой версией Node для поддержки apple silicon, это также завершает полную поддержку задач для macOS в Apple silicon. Агенты, работающие на Кремнии Apple, не нуждаются в Розетте для запуска.
По мере того как дата окончания жизни узла 16 перемещена вперед, мы начали работу по выполнению задач с node 20.
Увеличение ограничений Azure Pipeline для выравнивания с максимальным размером шаблона Azure Resource Manager (ARM) в 4 МБ.
Задачу развертывания шаблонов Azure Resource Manager можно использовать для создания инфраструктуры Azure. В ответ на ваши отзывы мы увеличили ограничение интеграции Azure Pipelines на 2 МБ до 4 МБ. Это соответствует максимальному размеру шаблонов ARM размером 4 МБ , разрешающим ограничения размера во время интеграции больших шаблонов.
Задача AzureRmWebAppDeployment поддерживает проверку подлинности идентификатора Microsoft Entra
Задачи AzureRmWebAppDeploymentV3 и AzureRmWebAppDeployment@4 были обновлены для поддержки Служба приложений с отключенной базовой проверкой подлинности. Если обычная проверка подлинности отключена в Служба приложений, задачи AzureRmWebAppDeploymentV3/4 используют проверку подлинности Идентификатора Microsoft Entra для выполнения развертываний в конечной точке Kudu Служба приложений. Для этого требуется последняя версия msdeploy.exe, установленной на агенте, которая относится к windows-2022/windows-latest Hosted agent (см . справочник по задачам).
Отключенная переопределение состояния политики покрытия кода на "Сбой" при сбое сборки
Ранее состояние политики покрытия кода переопределено на "Сбой" в случае сбоя сборки в PR. Это был блокировщик для некоторых из вас, которые имели сборку в качестве необязательной проверки и политики покрытия кода в качестве обязательной проверки для PR, что приводит к блокировке PR.
Теперь политика покрытия кода не будет переопределена на "Сбой" в случае сбоя сборки. Эта функция будет включена для всех клиентов.
Artifacts
Знакомство с поддержкой артефактов Azure для cargo Crates
Мы рады сообщить, что Azure Artifacts теперь предлагает встроенную поддержку контейнеров Cargo. Эта поддержка включает четность функций в отношении существующих протоколов, а также crates.io доступны в качестве вышестоящего источника. Разработчики и команды Rust теперь могут использовать, публиковать, управлять и предоставлять общий доступ к своим ящикам Cargo без проблем, при этом используя надежную инфраструктуру Azure и оставаясь в знакомой среде Azure DevOps.
Объявление об отмене для задач конвейера NuGet Restore версии 1 и NuGet Installer v0
Если вы используете задачи конвейера NuGet Restore версии 1 и NuGet Installer версии 0, быстро переходите к задаче конвейера NuGetCommand@2. Если вы не выполните этот переход, в скором времени в ваши конвейеры начнут поступать предупреждения. Если какие-либо действия не будут предприняты, с 27 ноября 2023 года работа ваших сборок будет завершаться сбоем.
Поддержка аудита npm в Azure Artifacts
Теперь артефакты Azure поддерживают npm audit и npm audit fix команды. Эта функция позволяет пользователям анализировать и устранять уязвимости своего проекта путем автоматического обновления небезопасных версий пакетов. Чтобы узнать больше о посещении, используйте аудит npm для обнаружения и устранения уязвимостей пакетов.
Отчетность
Новый интерфейс каталога панели мониторинга
Мы слушали ваши отзывы и рады представить новый интерфейс каталога панели мониторинга. Он не только имеет современный дизайн пользовательского интерфейса, но и позволяет сортировать по каждому столбцу с добавлением столбца Последней настройки . В этом столбце вы получите более подробные сведения об использовании общей панели мониторинга в коллекции проектов. Кроме того, теперь можно фильтровать по панелям мониторинга на уровне команды или проекта, что позволяет получить доступ только к списку необходимых элементов, скрывая панели мониторинга, которые вы не хотите просматривать.
Попробуйте сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps
Фильтрация рабочих элементов
Мы рады объявить фильтрацию диаграмм рабочих элементов. Эта функция позволяет наведите указатель мыши на диаграмму рабочего элемента для быстрого обзора и детализации определенных сегментов диаграмм для получения подробных сведений. Вам больше не нужно создавать настраиваемые запросы, чтобы получить доступ к нужному фрагменту данных. Теперь вы можете перейти к рабочим элементам в диаграммах рабочих элементов в нескольких щелчках мыши.
Ваши отзывы бесценны в формировании будущего этой функции. Попробуйте сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps.
Результаты покрытия кода для папок
Результаты покрытия кода теперь доступны для каждого отдельного файла и папки, а не только в качестве номера верхнего уровня. Представление покрытия кода отображается при нажатии кнопки режима представления папок. В этом режиме можно детализировать и просмотреть покрытие кода для выбранной поддеревки. Используйте кнопку переключателя для переключения между новыми и старыми представлениями.
Test Plans
Быстрое копирование и импорт с помощью тестового плана или идентификатора набора
Теперь вы можете легко обрабатывать несколько планов тестирования в планах тестирования Azure! Распознавание проблем, которые ранее сталкивались с длинными раскрывающимися меню для импорта, копирования или клонирования тестовых случаев, особенно для обширных планов или наборов, мы предприняли шаги по оптимизации рабочего процесса.
Мы рады сообщить о функции "Тестовый план" и "Поиск идентификаторов набора". Введите идентификатор плана тестирования или набора для быстрого импорта или копирования тестовых случаев без каких-либо задержек. Это обновление является частью нашей постоянной приверженности улучшению возможностей управления тестами, что делает его более интуитивно понятным и менее трудоемким.
Обновление для запуска тестов Azure
Мы рады поделиться тем, что средство запуска тестов Azure обновлено до более новой версии. Это обновление повышает стабильность и производительность, позволяя выполнять тесты без прерываний или задержек. Более ранняя версия тестового запуска Azure больше не поддерживается. Для повышения производительности и зависимости операций тестирования рекомендуется обновить до последней версии как можно скорее.
Новые возможности
- Улучшенная стабильность и производительность. Мы сделали значительные улучшения в тестовом средстве выполнения, устраняя проблемы, с которыми сталкиваются некоторые пользователи. Это обновление обеспечивает более надежный процесс тестирования, минимизируя нарушения работы.
- Запрос на обновление. Чтобы перейти к новой версии, появится запрос на обновление. Это гарантирует, что все пользователи могут легко перейти к улучшенной версии в удобном режиме, повышая совместимость и производительность.
Отзывы
Мы будем рады узнать ваше мнение! Вы можете сообщить о проблеме или предоставить идею и отслеживать ее с помощью Сообщество разработчиков и получить советы по Stack Overflow.