DevOps Built-in Access Levels, Security Groups and AAD Groups

Scenario:

in large organizations it’s so important that not all the colleagues who are working together on a project to be able to release/ deploy the product in production environment.

There must be always a check list to get ready for deploying in production. Nowadays this check list is called continuous integration/deploy (CI/CD).

The check list before deploy the product on production environment

Therefore the project team try to grant permission according to the responsibilities and tasks or each colleagues to team. On of the tools which we can use to develop a project with the agile method is Azure DevOps.

There is also possible to assign built-in Access Level and Security Group to each member of team as explained in follows.

The users/ members in Azure DevOps always have an assigned DevOps Group and Access Level.

DevOps Built-in Access Level

Access Level defines the Azure DevOps Features that a user or group can use.

Access Levels	Description
Basic	Basic supports full access to all Azure DevOps Board features
Stakeholders	Provides partial support for viewing and modifying work items but not using all features.
Visual Studio Subscriber	Free access to a limited set of features.

DevOps built-in security Groups

Security Groups define what users of groups can do with each Azure DevOps features.

Azure DevOps has mainly two different level of built-in groups [Microsoft Doc]:

Collection-Level
Project-Level

The Team Administrator is the person who can grant permissions to specific features.

Note

Your Text Here

Project-Level Security Groups

Each project contains the following built-in groups:

Build Administrator
Contributor
Project Administrators
Project Valid Users
Readers

<ProjectName> Team

DevOps Security Groups	Description [Microsoft Doc]
Project readers	Permission to view project information, the code base, work items, and other artifacts but not modify them.
Project Contributors	Permission to contribute fully to the project code base and work item tracking. They cannot manage or administrator resources.
Project Administrators	Permission to administer all aspects of teams and project. Although they cannot create team projects.

Combination Matrix of the Access Level and Security Group in Project-Level

DevOps Security Groups	Access Levels	Description
Project Readers	Stakeholder	–
Project Readers	Basic	–
Project Readers	Visual Studio subscriber	–
Project Contributors	Stakeholder	Managers or users who don’t actively contribute to the code base but want to check project status or provide direction, feedback, feature ideas, and business alignment to a team.
Project Contributors	Basic	Full-time workers who contribute to the code base or manage project.
Project Contributors	Visual Studio subscriber	Code base contribution
Project Administrators	Stakeholder	The users, who are tasked to managing project resources. If them also need to contribute to the code base, then the Basic Access Level must be assigned to them.
Project Administrators	Basic	Managing project resources + Code base contribution
Project Administrators	Visual Studio subscriber	Code base contribution

Combination Matrix of the Access Level and Security Group in Collection-Level

DevOps Security Groups	Access Levels	Description
Project Collection Administrators	Stakeholders	The users, who are tasked with managing organization or collection resources and if they need to be contributed to the code base then they must be assigned to Basic Access Level.
Project Collection Administrators	Basic	–
Project Collection Administrators	Visual Studio Subscriber	–

Azure DevOps Levels

DevOps can be configured at different levels:

Organization/Collection
Project
Object

The focus of this document is Project-Level and object-Level.

Object-Level Groups

Managing the permission on Git branches.

Using Azure ADD Group in Azure DevOps

For managing the users the Azure DevOps can be connected to Azure AD. The AAD Groups can be used in Azure DevOps as well. But the Active directory Group hierarchy is not usable in Azure DevOps. It means the sub groups will not inherit the access level and permission group of their parent group.

Each AAD parent and sub group must be added separately to Azure DevOps and an Access Level and a Permission Group must be assigned to each one separately them.

The users which are assigned to the same AAD Group will have the same Access Level and Permission Group, which has been assigned to this AAD group in Azure DevOps.

Note

Your Text Here

The Advantage is: