Управляемые пулы DevOps для Azure DevOps (предварительная версия)

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

Кроме того, мы улучшили API оценки использования счетчиков для GitHub Advanced Security, предоставляя новые возможности, которые помогают выявлять пользователей.

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

Расширенная безопасность GitHub для Azure DevOps

• API использования расширенного измерения безопасности теперь возвращает удостоверения пользователей
• Проверка кода расширенной безопасности GitHub для проектов C# и Java без сборок

Azure Pipelines (система конвейеров Azure)

• Управляемые пулы DevOps (предварительная версия)
• Задачи Azure Pipelines используют Node 20
• Предоставление разрешения на создание конвейера сборки
• Проверка эксклюзивной блокировки на уровне стадии
• Сведения о шаблоне в запусках конвейера
• Запуск этапов конвейера YAML вручную

Расширенная безопасность GitHub для Azure DevOps

API для использования функций усовершенствованной безопасности теперь возвращает идентификацию пользователей

Чтобы определить пользователей расширенной безопасности, API оценки использования счетчиков теперь возвращают удостоверение Azure DevOps каждого пользователя, включая отображаемое имя, CUID, идентификатор электронной почты и дескриптор удостоверения. Эта функция доступна на уровнях организации, проекта и репозитория. Чтобы использовать эту новую конечную точку, синтаксис аналогичен существующим конечным точкам API использования измерения, добавляя /details к конечной точке:

• На уровне организации: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
• На уровне проекта: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
• На уровне репозитория: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

Проверка кода расширенной безопасности GitHub для проектов C# и Java без сборок

Сканирование кода с помощью CodeQL включает выполнение запросов к базам данных, которые представляют код в репозитории для одного языка. Для скомпилированных языков, таких как C/C++, C#, Go, Java и Swift, обычно требуется сначала создать код.

Однако CodeQL, статический модуль анализа за GitHub Advanced Security для Azure DevOps, теперь может сканировать проекты C# и Java без необходимости сборки. Если для режима сборки задано значение none, база данных CodeQL создается непосредственно из базы кода, обходя шаг сборки.

Для всех скомпилированных языков режим сборки по умолчанию — "вручную". Однако для C# и Java можно изменить режим сборки на "нет".

Режим сборки можно настроить во время установки AdvancedSecurity-Codeql-Init@1. Подробные инструкции по настройке сканирования кода в GitHub Advanced Security с помощью Azure DevOps см. в статье "Настройка сканирования кода"

Рассмотрение:

• Если выбран параметр "нет" и язык, отличный от поддерживаемых языков C# или Java, задача конвейера может не работать должным образом.

• Режим сборки "none" в настоящее время работает вместе с другими интерпретируемыми языками (например, JavaScript, Python, Ruby).

• Допустимый пример: C# и JavaScript с режимом сборки, равным "none". (JavaScript в интерпретируемом языке)

• Недопустимый пример: C#, JavaScript и Swift с режимом сборки, заданным как none (Swift не поддерживается в режиме сборки none).

Azure Pipelines (система конвейеров Azure)

Управляемые пулы DevOps (предварительная версия)

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

Мы рады объявить о выходе общедоступной предварительной версии управляемых пулов DevOps (MDP), новой функции Azure DevOps, предназначенной для того, чтобы помочь командам разработчиков и инженеров платформы развертывать настраиваемые пулы DevOps, адаптированные к их уникальным потребностям. MDP объединяет гибкость Scale Set агентов с легкостью обслуживания, связанной с агентами, размещенными Microsoft, что позволяет командам устанавливать согласованность и лучшие практики при оптимизации производительности, безопасности, соответствия и экономичности.

К ключевым преимуществам управляемых пулов DevOps относятся:

• Размещено от вашего имени: MDP размещается и управляется корпорацией Майкрософт, виртуальные машины, обеспечивающие работу агентов, создаются и поддерживаются в подписках Azure, принадлежащих Майкрософт.
• Время, затраченное на управление: MDP значительно сокращает время, затраченное на управление агентами, особенно на основе локальной инфраструктуры или вручную поддерживаемых систем.
• Определенные пулы: Благодаря простоте создания новых пулов организации могут легко создавать несколько пулов для конкретной группы или рабочей нагрузки.
• Выставление счетов DevOps: MDP помогает оптимизировать счета DevOps команды с использованием множества функций. Это позволяет командам легко найти оптимальный баланс между качеством обслуживания и производительностью пула и затратами.
• Масштабируемый: MDP масштабируется до тысяч агентов в одном пуле.

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

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

Задачи конвейеров Azure используют Node.js 20

Большинство задач конвейера используют Node.js в качестве исполнительной среды. Задача в конвейерах Azure, которая использует NodeJS в качестве исполняющей среды, теперь работает на NodeJS 20. Авторы расширений задач должны обновить свои задачи, чтобы использовать Узел 20. Инструкции по обновлению см. в статье «Как обновить пользовательскую задачу до последней версии Node.js?».

Настройка прав для конвейера сборки

Чтобы повысить безопасность конвейера, мы представляем новое разрешение Create build pipelineна уровне конвейеров.

Edit build pipeline Ранее для создания или редактирования конвейера требуется разрешение. Это представляет угрозу безопасности, поскольку все пользователи, имеющие возможность создавать пайплайны, могли также изменять пайплайны, которые они не создавали. Предотвращение этого было трудоемким.

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

При создании конвейера его создатель получает Edit build pipeline разрешение.

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

Замечание

Разрешение на изменение конвейера сборки не предотвращает редактирование конвейера YAML другими пользователями; он защищает только свойства конвейера от изменения.

Для новых проектов пользователи и группы с разрешением Edit build pipeline также будут иметь разрешение Create build pipeline. Это может измениться в будущем.

Исключительная проверка блокировки на уровне стадии

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

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

В этом спринте мы представляем поддержку указания эксклюзивной блокировки на уровне этапа. Если у вас есть этап с идентификатором и вы указываете его lockBehavior свойство, для этого этапа автоматически создается блокировка. Поведение sequential остается согласованным как для блокировок уровня ресурсов, так и для блокировок уровня этапов. runLatest Однако поведение отличается, так как он отменяет runLatest только сборки для одной ветви, а не для всех ветвей конвейера.

Информация о шаблоне в выполнениях конвейера

Мы обновили REST API Pipelines Runs - Get, добавив информацию о шаблонах, которые были расширены и включены в запуск конвейера.

Например, рассмотрим следующий код конвейера YAML:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

Новый REST API имеет следующие новые свойства:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Запуск этапов конвейера YAML вручную

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

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

В этом спринте мы добавляем поддержку вручную запускаемых стадий пайплайна YAML. Чтобы использовать эту функцию, необходимо добавить свойство trigger: manual к стадии.

Рассмотрим следующий пример конвейера YAML:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

При запуске этого конвейера интерфейс выглядит следующим образом:

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

Дальнейшие шаги

Замечание

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

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

Перейдите в Azure DevOps

Как предоставить отзыв

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

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

Спасибо

Сильвиу Андреика