Edit

Share via

Managed DevOps Pools for Azure DevOps (preview)

  • Article

We’re excited to announce the preview of Managed DevOps Pools, designed to help development and platform engineering teams quickly set up and manage custom DevOps pools.

Additionally, we've enhanced the Meter Usage estimate APIs for GitHub Advanced Security, providing new capabilities that help you identify users.

Check out the release notes for details.

GitHub Advanced Security for Azure DevOps

Azure Pipelines

GitHub Advanced Security for Azure DevOps

Advanced Security meter usage API now returns user identities

To help you identify your Advanced Security users, the Meter Usage Estimate APIs now return each user’s Azure DevOps identity, including their display name, CUID, email identifier, and identity descriptor. This feature is available at the organization, project, and repository levels. To use this new endpoint, the syntax is similar to the existing meter usage API endpoints, appending /details to the endpoint:

  • At the organization level: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • At the project level: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • At the repository level: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

GitHub Advanced Security code scanning for C# and Java projects without builds

Code scanning with CodeQL involves running queries on databases that represent the code in your repository for a single language. For compiled languages like C/C++, C#, Go, Java, and Swift, this typically requires building the code first.

However, CodeQL, the static analysis engine behind GitHub Advanced Security for Azure DevOps, can now scan C# and Java projects without needing a build. When the build mode is set to "none," the CodeQL database is generated directly from the codebase, bypassing the build step.

For all compiled languages, the default build mode is "manual." However, for C# and Java, you can change the build mode to "none."

You can configure the build mode during the AdvancedSecurity-Codeql-Init@1 setup. For detailed instructions on configuring code scanning in GitHub Advanced Security with Azure DevOps, see Set up code scanning

Consideration:

  • If "none" is selected and a language other than supported complied languages C# or Java, the pipeline task may not work as expected.

  • Build mode "none" currently works in conjunction with other interpreted languages (e.g., JavaScript, Python, Ruby).

  • Valid Example: C# and JavaScript with build mode set to "none." (JavaScript in an interpreted language)

  • Invalid Example: C#, JavaScript, and Swift with build mode set to "none" (Swift is not supported in build mode "none").

Screenshot of AdvancedSecurity-Codeql.

Azure Pipelines

Managed DevOps Pools (preview)

Engineering teams excel when they can focus on writing code to develop applications and services for their users. However, in practice, a substantial amount of time is often spent managing other tasks, such as maintaining DevOps infrastructure.

We're excited to announce the public preview of Managed DevOps Pools (MDP), a new Azure DevOps feature designed to help development and platform engineering teams deploy custom DevOps pools tailored to their unique needs. MDP combines the flexibility of Scale Set agents with the ease of maintenance associated with Microsoft-hosted agents, enabling teams to establish consistency and best practices while optimizing performance, security, compliance, and cost-efficiency.

Key benefits of Managed DevOps Pools include:

  • Hosted on your behalf: MDP is hosted and managed by Microsoft, with the virtual machines powering the agents created and maintained within Microsoft-owned Azure subscriptions.
  • Time spent in Management: MDP significantly reduces the time spent managing agents, particularly those based on on-premises infrastructure or manually maintained systems.
  • Specific Pools: Due to the ease with which new pools can be created, organizations can easily create multiple team-specific or workload-specific pools.
  • DevOps Billing: MDP helps optimize a team’s DevOps bill through many features. It makes it easy for teams to find an optimal balance between a pool’s QoS/performance and cost.
  • Scalable: MDP scales to 1000s of agents in a single pool.

Teams can create pools with quick-starter images that contain the same software present in Microsoft hosted agents or with images the team has created with prerequisites that are unique to their scenario.

Learn more about Managed DevOps Pools by reading our blog post or its documentation.

Azure pipelines tasks use Node 20

Most pipeline tasks use Node as a runner. Azure pipelines task that use NodeJS as a runner now all use NodeJS 20. Authors of task extensions should update their tasks to use Node 20. For guidance on how to upgrade see, How can I upgrade my custom task to the latest Node?.

Create build pipeline permission

To increase pipeline security, we're introducing a new permission, Create build pipeline, at pipelines level.

Screenshot of create build pipeline permission.

Previously, the Edit build pipeline permission was required to create or edit a pipeline. This posed a security risk, as it allowed all users with the ability to create pipelines to also edit pipelines they didn't create. Preventing this was time-consuming.

To enhance your pipeline experience without compromising security, all users and groups with the Edit build pipeline permission will now also receive the Create build pipeline permission.

When a pipeline is created, its creator is granted the Edit build pipeline permission.

For improved pipeline security, you may choose to remove the Edit build pipeline permission from user groups such as Contributors and Readers. This ensures that, by default, only the pipeline's creator can edit it.

Note

The Edit build pipeline permission does not prevent others from editing a YAML pipeline; it only protects the pipeline's properties from being edited.

For new projects, users and groups with the Edit build pipeline permission will also have the Create build pipeline permission. This is subject to change in the future.

Exclusive lock check at stage level

Some use cases require a pipeline to access a specific resource only once at any given time. To support this case, we have the Exclusive lock check.

A similar situation arises when only one pipeline run should access a stage at any point in time. For instance, if you have a stage that deploys to an Azure resource group, you may want to prevent multiple pipeline runs from simultaneously updating the same resource group. Currently, achieving this requires using a proxy resource, such as an environment, and placing the Exclusive lock check on that environment. This approach can be time-consuming, add complexity, and increase maintenance efforts.

In this sprint, we’re introducing support for specifying the exclusive lock at the stage level. If you have a stage with an ID and specify its lockBehavior property, a lock is automatically created for that stage. The sequential behavior remains consistent for both resource-level and stage-level locks. However, the runLatest behavior differs, as it only cancels runLatest builds for the same branch, not for all branches of the pipeline.

Template information in pipeline runs

We updated the Pipelines Runs - Get REST API with information about the templates extended and included in a pipeline run.

For example, consider you have the following YAML pipeline code:

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

The new REST API has the following new properties:

"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"
    }

Manually triggered YAML pipeline stages

We frequently receive requests about manually triggered YAML pipeline stages. These are helpful when you want a unified pipeline but don’t always want it to run to completion.

For instance, your pipeline might include stages for building, testing, deploying to a staging environment, and deploying to production. You might want all stages to run automatically except for the production deployment, which you prefer to trigger manually when ready.

With this sprint, we're adding support for manually triggered YAML pipeline stages. To use this feature, you need to add the trigger: manual property to a stage.

Consider the following YAML pipeline example:

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'''

When you run this pipeline, the experience is as follows:

Screenshot of manually triggered YAML pipeline stages.

Manually triggered stages have no dependencies and can be run at any time. The pipeline run completes when there are only manually triggered stages left to execute.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Silviu Andrica