Events
Mar 17, 9 PM - Mar 21, 10 AM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowEnhanced 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.
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.
For more information, see Security overview for Advanced Security.
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:
- Create a new connection in Azure Boards.
- Select the GitHub Enterprise Cloud with data residency option.
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:
YAML
checkout: repo
sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAML
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.
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:
After:
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 returnsvalue_when_truewhenconditionevaluates totrueorvalue_when_false, otherwisetrim(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.
YAML
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)}}
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 / teamsallowApproversToApproveTheirOwnRuns: 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.
YAML
- 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]
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.
Note
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Silviu Andrica
Additional resources
Training
Learning path
AZ-400: Implement a secure continuous deployment using Azure Pipelines - Training
AZ-400: Implement a secure continuous deployment using Azure Pipelines
Certification
Microsoft Certified: DevOps Engineer Expert - Certifications
This certification measures your ability to accomplish the following technical tasks: Design and implement processes and communications, design and implement a source control strategy, design and implement build and release pipelines, develop a security and compliance plan, and implement an instrumentation strategy.