編集

次の方法で共有

Enhanced security and Pipeline workflows

  • [アーティクル]

With this sprint, we’re enhancing your DevOps workflow with greater security visibility and streamlined pipeline workflows. GitHub Advanced Security now includes detailed enablement tracking for dependency scanning, code scanning, and secret scanning, offering deeper insights into your organization’s security coverage.

In addition, we're excited to introduce pipeline-focused enhancements, including new YAML expression functions and expanded controls for manual validation tasks, enabling you to create more efficient and secure workflows.

Check out the release notes for details.

GitHub Advanced Security for Azure DevOps

Azure Boards:

Azure Repos

Azure Pipelines

Test Plans

GitHub Advanced Security for Azure DevOps

Tool specific security overview coverage

The security overview in GitHub Advanced Security for Azure DevOps now provides a detailed breakdown of enablement status for each scan tool, including dependency scanning, code scanning, and secret scanning. This enhancement allows you to view fine-grained enablement statuses across all repositories in your organization.

Screenshot of security overview.

For more information, see Security overview for Advanced Security.

Azure Boards

Azure Boards Integration with GitHub Enterprise Cloud with Data Residency

Azure Boards now supports integration with GitHub Enterprise Cloud organizations that have data residency enabled. This update aligns with GitHub’s September 2024 announcement introducing data residency for Enterprise Cloud customers, starting with those in the European Union (EU).

To connect an Azure Boards project to your GitHub Enterprise Cloud organization with data residency:

  1. Create a new connection in Azure Boards.

Screenshot of connect github with boards.

  1. Select the GitHub Enterprise Cloud with data residency option.

Screenshot of new github connection.

Azure Repos

Sparse checkout for Azure Repos

The git sparse-checkout command is now supported in the YAML checkout task, alongside the partial clone filter, to improve repository checkout performance. You can use the properties sparseCheckoutDirectories and sparseCheckoutPatterns.

Setting sparseCheckoutDirectories enables cone mode, where the checkout process uses directory matching. Alternatively, you can set sparseCheckoutPatterns which triggers non-cone mode, allowing more complex pattern matching.

If both properties are set, the agent initializes cone mode with directory matching. If neither property is specified in the checkout task, the sparse checkout process is disabled. Any issues encountered during command execution results in the checkout task failing.

YAML example for sparse checkout cone mode:

    checkout: repo
    sparseCheckoutDirectories: src

YAML example for sparse checkout non-cone mode:


   checkout: repo
   sparseCheckoutPatterns: /* !/img

Important

The sparse checkout feature requires agent v3.248.0 (v4.248.0 for .NET 8) or later versions.

You can find the agent on the releases page.

Make cross-repo policies case-sensitive

Previously, the branch candidate preview for cross-repo policies displayed results in a case-insensitive manner, despite branch matching being case-sensitive. This inconsistency created potential misalignment, as it could appear that certain branches were protected when they weren't. To resolve this issue, we have updated the branch pattern preview to align with the case-sensitive behavior of policy application.

Previously:

Screenshot of before fix

After:

Screenshot of after fix.

Azure Pipelines

New pipeline expression functions

Pipeline expression functions allow you to write powerful YAML pipelines. In this sprint, we've introduced two new functions:

  • iif(condition, value_when_true, value_when_false) that returns value_when_true when condition evaluates to true or value_when_false, otherwise

  • trim(string) that returns a new string in which whitespaces at the beginning and end of the string are removed

For example, you can use the iif function to dynamically select a pool for running your pipeline. If you want to build pull requests using the Azure Pipelines pool, but all other runs should use a Managed DevOps pool, you can write the following pipeline.

variables:
  poolToUse: ${{ iif(eq(variables['Build.Reason'], 'PullRequest'), 'Azure Pipelines', 'ManagedDevOpsPool')}}

stages:
- stage: build
  pool: ${{variables.poolToUse}}
  jobs:
  - job:
    steps:   
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'

You can use the trim function to make your YAML more resilient to user input. For example, in the following pipeline, we use the trim function to ensure the stage name doesn't start with white spaces.

parameters:
- name: regions
  type: string
  default: '  wus1,   wus2, wus3,wus4'

stages:
- ${{ each region in split(parameters.regions, ',')}}:
  - stage: stage_${{trim(region)}}
    displayName: Deploy to ${{trim(region)}}
    jobs:
    - job: deploy
      steps:
      - script: ./deploy.sh ${{trim(region)}}

Enhancements to ManualValidation task

The ManualValidation task enables you to pause a pipeline run and wait for manual intervention. One scenario for using this task is manual testing.

To increase security of your pipeline, you may wish to restrict who can complete the task and resume the pipeline run. To this end, we're introducing a new version of the task that provides two additional parameters:

  • approvers: restrict who can complete the task to a predefined set of users / security groups / teams

  • allowApproversToApproveTheirOwnRuns: restrict the user who queued the pipeline run from resuming it

For example, the following YAML snippet restricts the set of people who can resume the pipeline run to members of the Release Approvers group, but not by the user who triggered the pipeline run.

- task: ManualValidation@1
  inputs:
    notifyUsers: 'Release Approvers'
    approvers: 'Release Approvers'
    allowApproversToApproveTheirOwnRuns: false

In the approvers property, you can use the following values (comma separated) :

  • Email address,
  • Permission-Group,
  • Project-Team,
  • [ProjectName][Permission Group],
  • [Org][Permission Group],
  • [ProjectName][Project Team]

Test Plans

Azure Test Plans bug fixes

With this sprint, we’ve made updates to Azure Test Plans to resolve several bugs and improve usability. Here’s what’s been fixed:

  • Shared step results vow visible: Fixed a bug where shared step results wouldn’t appear in the query editor when accessing test cases in the New Boards Hub.

  • Improved stakeholder mode sessions: Resolved an issue in the test and feedback extension that blocked users with stakeholder access from starting sessions.

  • Cleaner test plan copying: Fixed a problem where requirements were duplicated when copying a Test Plan using the “Reference Existing Test Cases” option.

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