The CI/CD pipeline is a DevOps practice for delivering code changes more frequently, consistently, and reliably. It enables Agile teams to increase deployment frequency, decrease lead time for change, change failure rate, and mean time to recovery key performance indicators, thereby improving quality and delivering value faster.
Let's use Active Directory (AD) security groups
After our dream for One CI/CD pipeline to rule them all we decided to go one step further and simplify the classic release pipeline security using Active Directory (AD) groups. Instead of assigning and managing permissions for users in Azure DevOps, we use Azure Active Directory groups to fine tune permissions. For example, we have project specific super users AD groups that grant elevated permissions to edit release pipelines and the development and system test stages.
Bookmark the Azure DevOps DRIFT project, which will enable you to monitor and remediate configuration drift, for example to automatically remove explicit user accounts added to an AD driven security model.
Why AD groups?
The value of using AD groups depends on your environment. In our case the benefits are:
- AD groups and memberships are centrally managed and audited.
- AD groups membership is track than individual user accounts spread across multiple Azure DevOps services and projects.
- Azure DevOps users are empowered to request group membership using an existing process, rather than relying on the Azure DevOps project collection and project administrators.
- Simplifies automation of pipeline generation and configuration.
Let's use email-enabled Active Directory (AD) security groups
But wait, we can go a step further and use mail-enabled AD security groups for pre- and post-stage pipeline approvals.
We replace the individual users highlighted in yellow with Release Approval AD groups.
Why are there no stage approval notifications?
We realized that some of our email-enabled AD security groups received no notifications and spend time with Microsoft support to identify the root cause(s).
You have to ensure that the AD security groups:
- Are mail-enabled and authorized to receive external emails.
- Have View Releases permissions on release and definitions.
- Have a subscription that is enabled for the group(s).
The second bullet is the one that caught us off guard. If the permission is missing the Azure DevOps Pipeline event/notification service filters out the account's notifications. When notifications are filtered, no email is sent for impacted group(s) - silence prevails.
Make sure that your email-enabled AD security groups are members of your project Contributors or Readers, which by default, have the View Releases permission.
Watch the space for unified multi-stage YAML-based pipeline learnings.