Заметки о выпуске Azure DevOps Server 2022 с обновлением 2


| | Сообщество разработчиков Системные требования и совместимость | Условия | лицензииDevOps Блог | SHA-256 Хэши |


В этой статье вы найдете сведения о новейшем выпуске для Azure DevOps Server.

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

Чтобы скачать 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 необходимо выполнить некоторые промежуточные действия. Дополнительные сведения см. на странице Установка .


Azure DevOps Server 2022 обновление 2 RC Дата выпуска: 7 мая 2024 г.

Azure DevOps Server версии-кандидат 2022.2 включает множество новых функций. Вот некоторые из них:

Вы также можете перейти к отдельным разделам, чтобы просмотреть все новые функции для каждой службы:


Общее

Задача "Публикация результатов теста"

Задача Публикация результатов теста теперь поддерживает вложения тестового запуска для формата отчета JUnit.

Новая версия пакета SDK для веб-расширения Azure DevOps

В этом обновлении мы выпускаем новую версию пакета SDK для веб-расширения Azure DevOps. Клиентский пакет SDK позволяет веб-расширениям обмениваться данными с кадром узла. Его можно использовать для:

  • Уведомление узла о том, что расширение загружено или имеет ошибки
  • Получение основных контекстных сведений о текущей странице (сведения о текущем пользователе, узле и расширении)
  • Получение сведений о теме
  • Получение маркера авторизации для использования в обратных вызовах REST к Azure DevOps
  • Получение удаленных служб, предлагаемых кадром узла

Полный справочник по API можно найти в документации по пакету azure-devops-extension-sdk. Эта новая версия обеспечивает поддержку следующих модулей:

  • Поддержка модулей ES: Пакет SDK теперь поддерживает модули ES (ECMAScript) в дополнение к существующим модулям AMD (асинхронное определение модуля). Теперь вы можете импортировать пакет SDK с помощью синтаксиса модуля ES, который повышает производительность и уменьшает размер приложения.

  • Обратная совместимость для модулей AMD: Существующая поддержка модулей AMD остается неизменной. Если в проекте используются модули AMD, вы можете продолжать использовать их, как и раньше, без каких-либо изменений.

Как использовать:

Для модулей ES можно импортировать наши модули с помощью инструкции import:

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 для каждого проекта как для областей, так и для путей итерации. Дополнительные сведения о различных ограничениях в службе см. на странице Ограничения для работы , процессов и проектов .

Снимок экрана: области и пути итерации.

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

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

Снимки экрана: службы DevOps.

При переходе к рабочему элементу соответствующие элементы управления Разработка и Развертывание будут скрыты в форме.

Снимки экрана со связанными работами.

Если вы решите подключить репозиторий GitHub к Azure Boards, отобразится элемент управления Разработка для репозиториев GitHub.

Снимок экрана: элемент управления разработки .

Repos

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

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

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

На следующем рисунке показан запрос на вытягивание, созданный пользователем A, и дополнительные 4 фиксации (итераций), выполненные в этом запросе пользователями B, C, A again и C. После завершения второй итерации (фиксации, выполненной пользователем B), пользователь C одобрил ее. В то время это подразумевало утверждение первой фиксации пользователя A (при создании запроса на вытягивание), и новая политика будет успешной. После пятой итерации (последней фиксации пользователя C) утверждение было выполнено пользователем A. Это подразумевало утверждение для более ранней фиксации, выполненной пользователем C, но не подразумевало утверждение второй фиксации, выполненной пользователем A в четвертой итерации. Для успешного выполнения новой политики неутвержденная итерация четыре должна быть одобрена пользователем B, C или любым другим пользователем, который не внес никаких изменений в запрос на вытягивание.

Образ управления разрешениями.

Примечание

Существует известная проблема, из-за которой политики ветвей принимают группу, настроенную в качестве рецензента, в качестве утверждающей сущности. Давайте представим, что требуется утверждение любого пользователя группы G. Пользователь А является членом этой группы G. После того как пользователь A предоставит утверждение, как показано на рисунке выше (после пятой итерации), утверждение группы G утверждает изменения, выполненные пользователем A. Это не ожидается и будет устранено в выпуске RTW.

Поддержка фильтров без больших двоичных объектов и без деревьев

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

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

 Снимок экрана: триггер CI YAML.

Повторите попытку, когда истекает время ожидания утверждений и проверок

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

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

Снимок экрана: повторная попытка этапа.

Обход утверждений и проверок

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

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

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

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

Вы можете обойти выполняемые утверждения, рабочие часы, вызов функции Azure и вызов проверок REST API.

Обход утверждения.

Снимок экрана: обход утверждения.

Обход проверка рабочих часов.

Снимок экрана: обход рабочих часов проверка.

Обход вызова функции Azure проверка. Обход проверка рабочих часов.

Снимок экрана: обход вызова функции Azure проверка.

При обходе проверка его можно увидеть на панели проверок.

Снимок экрана: обход проверка.

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

Снимок экрана: обязательный шаблон YAML.

Повторный запуск проверки функций Azure

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

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

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

Снимок экрана: динамические проверка.

Примечание

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

Поддержка GitHub Enterprise Server в обязательных проверка шаблонов

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

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

Теперь можно указать шаблоны, расположенные в репозиториях GitHub Enterprise Server.

Роль администратора для всех сред

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

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

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

Снимок экрана: роль администратора.

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

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

Улучшенная проверка YAML

Чтобы проверить правильность синтаксиса YAML, можно использовать функцию Проверки веб-редактора Azure Pipelines. Таким образом, важно, чтобы эта функция перехватывала как можно больше проблем YAML.

Снимок экрана: проверка 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. Опять же, в условии есть опечатка, и функция Проверить отобразит его.

Снимок экрана: переменная patch.

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 GET REST API возвращает

{
    "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, использующие Node в качестве средства выполнения, теперь используют Узел 16. Так как Node 16 является первой версией Node с изначальной поддержкой Apple Silicon, это также завершает полную поддержку задач для macOS на Apple Silicon. Агенты, работающие на apple silicon, не нуждаются в Rosetta для запуска.

По мере перемещения даты окончания жизненного дня узла 16 мы начали работу по выполнению задач с узлом 20.

Объявление об отмене устаревших задач

В Azure Pipelines есть много устаревших задач. Устаревшие задачи будут прекращены 31 января 2024 г. Чтобы помочь определить конвейеры, использующие нерекомендуемые задачи, в конвейерах будут отображаться предупреждения, если такая задача используется. Мы обновили справочник по задачам , чтобы четко указать состояние устаревания и дату прекращения поддержки.

Следующие задачи устарели и начнут выдавать предупреждения:

  • AppCenterDistributeV1,
  • AppCenterDistributeV2
  • AzureMonitorV0
  • ChefKnifeV1
  • ChefV1
  • CondaEnvironmentV1
  • DeployVisualStudioTestAgentV2
  • DotNetCoreInstallerV1
  • IISWebAppDeployment
  • QuickPerfTestV1
  • RunJMeterLoadTestV1
  • RunLoadTestV1
  • SqlServerDacpacDeploymentV1
  • XamarinTestCloudV1

Обновите конвейеры, чтобы использовать более новую версию задачи или альтернативу до 31 января 2024 г.

Увеличены ограничения Azure Pipeline в соответствии с максимальным размером шаблона azure Resource Manager (ARM) в 4 МБ.

Для создания инфраструктуры Azure можно использовать задачу "Развертывание шаблона Resource Manager Azure". В ответ на ваши отзывы мы увеличили лимит интеграции Azure Pipelines с 2 ДО 4 МБ. Это будет соответствовать максимальному размеру шаблонов ARM в 4 МБ , разрешающим ограничения размера во время интеграции больших шаблонов.

Задача AzureRmWebAppDeployment поддерживает проверку подлинности Microsoft Entra ID

Задачи AzureRmWebAppDeploymentV3 и AzureRmWebAppDeployment@4 обновлены для поддержки Служба приложений с отключенной обычной проверкой подлинности. Если обычная проверка подлинности на Служба приложений отключена, задачи AzureRmWebAppDeploymentV3/4 используют проверку подлинности Microsoft Entra ID для выполнения развертываний в конечной точке Kudu Служба приложений. Для этого требуется последняя версия msdeploy.exe, установленная в агенте, что относится к размещенным агентам windows-2022/windows-latest (см. справочник по задачам).

Отключено переопределение состояния политики покрытия кода на Сбой при сбое сборки

Ранее состояние политики покрытия кода было переопределено на "Сбой", если сборка в запросе на вытягивание завершилась сбоем. Это было блокированием для некоторых из вас, у которых сборка была необязательным проверка и политика покрытия кода в качестве обязательного проверка для PRs, что привело к блокировке PR.

Снимок экрана: блокировка PR.

Теперь политика покрытия кода не будет переопределена на "Failed" в случае сбоя сборки. Эта функция будет включена для всех клиентов.

Снимок экрана: результаты после изменения.

Artifacts

Знакомство с поддержкой Azure Artifacts для грузовых ящиков

Мы рады сообщить, что Azure Artifacts теперь предлагает встроенную поддержку контейнеров Cargo. Эта поддержка включает в себя паритет функций по отношению к существующим протоколам, а также crates.io доступны в качестве источника вышестоящий. Разработчики и команды Rust теперь могут легко использовать, публиковать, администрать и совместно использовать свои ящики Cargo, используя надежную инфраструктуру Azure и оставаясь в знакомой среде Azure DevOps.

Объявление об устаревании для задач конвейера Восстановления NuGet версии 1 и Установщик NuGet версии 0

Если вы используете задачи конвейера NuGet Restore версии 1 и Установщик NuGet версии 0, быстро переходите к задаче конвейера NuGetCommand@2. Вскоре вы начнете получать оповещения в конвейерах, если переход еще не выполнен. Если никаких действий не предпринять, начиная с 27 ноября 2023 г., сборки приведут к сбою.

Поддержка аудита npm в Azure Artifacts

Azure Artifacts теперь поддерживает npm audit команды и npm audit fix . Эта функция позволяет пользователям анализировать и устранять уязвимости своего проекта путем автоматического обновления небезопасных версий пакетов. Дополнительные сведения см. в статье Использование аудита npm для обнаружения и устранения уязвимостей пакетов.

Отчеты

Новый интерфейс каталога панели мониторинга

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

Gif для демонстрации нового каталога панели мониторинга.

Попробуйте прямо сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps

Фильтрация рабочих элементов

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

Gif для демонстрации фильтрации рабочих элементов.

Ваши отзывы неоценимы в формировании будущего этой функции. Попробуйте сейчас и сообщите нам, что вы думаете в нашем сообществе Azure DevOps.

Результаты покрытия кода для папок

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

Мини-приложение с несколькими репозиториями в общедоступной доступности

Test Plans

Быстрое копирование и импорт с помощью плана тестирования или идентификатора набора

Теперь вы можете легко обрабатывать несколько планов тестирования в Azure Test Plans! Учитывая проблемы, с которыми ранее сталкивались длинные раскрывающиеся меню для импорта, копирования или клонирования тестовых случаев, особенно для обширных планов или наборов, мы приняли меры для оптимизации рабочего процесса.

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

Gif для демонстрации плана тестирования, сведения о поиске по идентификатору набора.

Обновление средства выполнения тестов Azure

Мы рады сообщить, что средство выполнения тестов Azure обновлено до новой версии. Это обновление повышает стабильность и производительность, позволяя выполнять тесты без прерываний или задержек. Более старая версия средства выполнения тестов Azure больше не поддерживается. Чтобы обеспечить оптимальную производительность и надежность операций тестирования, рекомендуется как можно скорее выполнить обновление до последней версии.

Новые возможности

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

Снимок экрана: запрос на обновление.


Отзывы

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


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