So I’ve been a big fan of Azure Dev Ops, since its original version. The idea of creating something for operations to manage in Team Foundation Server always made me shake my head. Developer tooling, methodology and needs are always changing, so a SaaS offering really is the best option. I always laugh when people question this idea, because GitHub.
Now the one thing I’ve seen a lot of questions around though, is Governance. Because after all, as you adopt tools like this, they become mission critical to all of your software development efforts. So how do I configure this thing to be setup correctly.
There are several things you can to make sure you’ve configured governance for Azure Dev Ops. I’m going to cover some of the high points here to get you started.
Leverage Azure AD
One of the biggest recommendations I have is to leverage Azure AD for your backend identity store if at all possible. The reason I say this is that Azure AD provides a robust identity store, that allows for managing users in groups. It is my belief that no individual users should be added to Azure Dev Ops, but instead that groups should be leveraged as part of Azure AD. This provides several options which can help with the management.
- Enable authentication with the same accounts your users leverage for Microsoft 365 and the Azure Portal.
- If you don’t use those services you can leverage federation with other identity store to provide integration with existing IDPs.
- Simplifies management for adding users and exit procedures.
- Keeps access to only those that need the tool, this keeps people like internal IT operations from having admin permissions in ADO, and rather limits them to the Azure AD.
- Able to integrate more advanced features like MFA.
You can configure access with Azure AD by following this. And here’s a great article that walks through how to create organizations and connect them with Azure AD.
Use Organizations
Organizations are keys to Azure DevOps governance, as they provide a means of creating access controls around projects, work item tracking, source control, pipelines, etc.
Now when it comes to structuring your organization, there are several things you can do to ensure success. Here are some general recommendations from the ADO documentation.
Really you want to make sure you structure your projects and repos according to the work your doing, and potentially leverage the idea of teams where needed.
I find there are a couple of things to keep in mind when you structure your organization, and I’m going to give those instead of specific guidance and a “This is the only structure that works”.
- Projects should be self contained – Projects themselves should include all components from work items, source code, pipelines, and testing for a single project.
- Projects should represent a key security boundary. This is really easy, so if you take the above, and make these as self-contained. Ultimately it makes it really easy to make this a security boundary.
- Break out repos within a project. I am not a fan of making every element of your project exist in one repo. This causes a lot more problems when you try to build your pipeline and can make your builds take forever.
- Group work items and boards in such a way that makes sense for your team. I’m a big ALM guy but I have to be honest too many times people say “But agile says…” and the truth is in the agile manifesto it calls out the need to focus on delivering software and doing so in a way that makes sense.
Ultimately there are lots of ways to do the above, but these are my recommendations for where to start.
Here are some additional links to help get you started:
- Plan your organization structure
- About organization management in Azure DevOps
- Access your organization with Azure AD
- Manage Access with Azure AD groups
- Add Organization users to your active directory
- Restrict Organization Creation with Azure AD Tenant policy
- Setting Permissions at the project or collection level
- Add AD / Azure AD users or groups to built-in security groups
- About Permissions and Groups
- About Security Roles
- Key Security Concepts
Oldest comments (0)