Source control repositories are an important part of software development. They ensure that data can always be recovered and they also enable continuous integration. Azure DevOps includes features common to modern software development such as source control repositories, continuous integration pipelines, agile planning tools, and more. This course covers several topics which fall under the umbrella of configuring repositories for Azure DevOps.
Learning Objectives
- Integrating GitHub repositories with Azure DevOps Pipelines
- Configuring permissions in source control repositories
- Configuring tags to organize source control repositories
- Recovering data using Git commands
- Purging data from source control
Intended Audience
- Software engineers
- DevOps engineers
- Site reliability engineers
Prerequisites
- Be comfortable using Git
- Be familiar with Azure DevOps
Hello and welcome. In this content, we'll explore how to configure permissions for Azure DevOps source control repositories. Azure DevOps repositories enable the creation of one or more Git repositories per project. Repositories can control the allowed actions for users and groups through permissions. Azure DevOps repositories allow permissions to be applied at different levels and inherited from higher levels. Repository permissions can be applied at the following levels: project, repository, and branch.
Some of the types of permissions available include contribute, contribute to pull requests, create branch, create tag, read, and rename repository, to name a few. Let's observe how to manage permissions at these different levels. I'm on the repository's page of the project settings. There are two repositories created for this project. Clicking the security tab displays the permissions configuration interface. These settings are applied to all repositories. Notice permissions can be applied to users and groups.
The built-in groups listed provide a convenient starting point for configuring permissions. Notice the specific permissions allow one of the three options to be specified; not set, allow, and deny. Not set enables permissions to be inherited from higher levels. Allow and deny are explicit permissions that override inherited permissions. I'm going to use this service account user to demonstrate permissions being applied. Changing the contribute permissions to allow enables this user to contribute to all repositories for the project. The green check beside the drop-down indicates that the change was saved.
I'm going to navigate to the permissions page for the first of the two repositories. Notice what happens when I select the service account user. The contribute permissions is set to allow inherited. Inheritance can be enabled and disabled at each level. The default is to enable inheritance. This toggle button controls inheritance for the current level. Each level has one of these buttons. Branch-level settings are applied outside the project setting's page. I'm going to navigate to the branch-level settings. I'll select 'Repose' on the left-hand side navigation, followed by 'Branches'. Notice a repository was not explicitly selected.
A repository is selected by default. Perhaps it selects the first in the list, I'm not exactly sure of the selection logic. However, the repository can be changed using the breadcrumbs at the top of the page. Selecting the repository opens up an interface which allows other repositories to be selected. I'm going to keep this repository selected since it has multiple branches. This table lists the existing branches. Hovering over the rows displays an ellipsis on the right side of the row. Selecting it opens a sub menu containing branch-level options. The branch security option opens up the permissions interface.
I'm going to remove contribute permissions for the service account user solely for the selected branch. I'm going to switch to another branch to demonstrate that this change is only applied to the selected branch. Notice a service account user has contributed permissions for this other branch. Source code level security is important for preventing unauthorized source code from ending up running in production, as well as preventing unauthorized users from gaining access. Azure DevOps makes it relatively easy to configure permissions at multiple levels. Okay, we're going to wrap up here. I hope this demonstration has been helpful. Thanks for watching.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.