Поделиться через


Azure Pipelines — обновление Sprint 230

Функции

Задачи Azure Pipelines используют узел 16

Задачи в конвейере выполняются с помощью средства выполнения с использованием Node.js, используемого в большинстве случаев. Задачи Azure Pipelines, использующие узел в качестве бегуна, теперь используют узел 16. Так как Node 16 является первой версией Node для поддержки apple silicon, это также завершает полную поддержку задач для macOS в Apple silicon. Агенты, работающие на Кремнии Apple, не нуждаются в Розетте для запуска.

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

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

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

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

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

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

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

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

Улучшения rest API Утверждения

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

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

Например, следующий вызов https://dev.azure.com/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"
            }
        }
    ]
}

Обход Утверждения и проверок

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

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

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

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

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

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

Screenshot of Bypass an Approval.

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

Screenshot of Bypass Business Hours check.

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

Screenshot of Bypass Invoke Azure Function check.

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

Screenshot of check bypassed.

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

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

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

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

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

Screenshot of required YAML template.

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

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

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

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

Screenshot of dynamic check.

Примечание.

Вы можете повторно запустить проверка только в том случае, если вы являетесь Администратор istrator ресурса, на котором определены проверка.

Следующие шаги

Примечание.

Эти функции будут развернуты в течение следующих двух-трех недель.

Перейдите к Azure DevOps и посмотрите.

Отправка отзыва

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

Make a suggestion

Вы также можете получить советы и ваши вопросы, ответы сообщества на Stack Overflow.