Most Important and Key Features in Azure DevOps

What’s Covered Here?

This article covers some of the most important and key features in Azure DevOps that are critical to know in any production environment. This is not a fundamental Azure DevOps tutorial and readers are assumed to have introductory knowledge on Azure DevOps though it will cover a basic introduction to start with.

If you are new to Azure DevOps then I recommend going through Microsoft learn https://docs.microsoft.com/en-us/learn/certifications/devops-engineer which covers Azure DevOps in great detail. You can also go through tons of youtube channels covering detailed tutorials. Click this to visit the official Azure DevOps channel.

Azure DevOps – Introduction

DevOps is all about reducing wastage and automating all redundant and repeating activities from the software development lifecycle. Idea is that teams focus on what’s important and adding more value rather than spending time on activities that are repeating and low valued. Also, DevOps is about unifying Development, Testing , Operations and Business folks into a single team and making everyone equally responsible right from the start. This again helps in reducing the waste by eliminating cycles of rework and keeping everyone involved to avoid last minute changes. DevOps and Agile processes goes hand in hand and in a way the birth of Agile led to the birth of DevOps. Its also important to understand that DevOps is not an end goal but a continuous process to improve ways of working. To reduce waste and add better value, DevOps teams leverage available automation tools and procedures catering to different needs in SDLC.

In all the available products, Azure DevOps is one of the most extensive and complete product available in the market today. With Azure DevOps, Microsoft has unified multiple products and services catering to different automation requirements into a single product. It is way ahead of its competitors since there aren’t many in the market providing end to end DevOps solution spanning all SDLC phases. With Azure DevOps we get the following key features and services:

Let’s dive into Key Features

OK, enough of fundamentals and let’s get to the crux. Below is the list of key features in Azure DevOps categorized according to their scope. These will be explained in order. With each item, effective reasoning will also be provided where ever applicable and important.

Scope – Azure DevOps Organization

• How to connect Azure DevOps Organization with Azure AD
• Add Users and Group Rules in an Azure DevOps Organization
• How to add custom Groups in an Azure DevOps Organization
• How to Opt-out from Notifications sent by Azure DevOps at a User level
• How to connect third party services with Azure DevOps Organization

Scope – Azure DevOps Project

• Things already covered with Organization scope
• Add Branch Policies for Azure DevOps Project Repository
• How to check Build Agent’s capabilities

Scope – Azure DevOps Pipelines

• YAML Pipeline Benefits
• How to create cross project reference pipelines
• How to control Pipeline tasks execution using condition
• List of most important and useful Pipeline extensions and their usage

Azure DevOps Organization Key Features

1. How to connect Azure DevOps with Azure Active Directory

In an enterprise using Azure DevOps, the very first step is to create an Azure DevOps organization. This organization acts as a parent entity and represents the actual physical organization in Azure. Once the organization is in place, DevOps team needs to add all Users, Groups and Permissions at the DevOps organization level. These users (organization employees or partner users), groups and permissions apply globally at the organization level and later becomes available when projects are created under this Organization. To start with the process, we get these users and groups from Azure Active Directory.

Reasoning – Azure DevOps Organization will have Projects , Repositories , Pipelines and other services which will be managed by our organization employees such as Administrator , Developers, Testers, BAs, Product Owners etc. Enterprises maintain their employee base (users), groups, domains, systems and applications in some sort of directory service. In Microsoft platform directory service used is Active Directory Domain Services for On-Premise systems and Azure Active Directory (AAD) for Azure cloud environment. In order to get these enterprise users and groups in Azure DevOps, we need to connect Azure DevOps organization with Azure AD. If a company is still using on-premise model, they would still need to have Azure AD tenant in place to sync On-premise AD with Azure AD before connecting Azure DevOps with Azure AD. Azure DevOps doesn’t provide any option to connect to On-premise AD.

How to do it –

• As a user having Administrative permissions in Azure AD and Azure DevOps, login to Azure DevOps and move to your Azure DevOps Organization. (Assuming DevOps Organization is already created)
• Open organization settings and you should see “Azure Active Directory“
• Open the dialog and there we should be able to see the connectivity option. Select the directory and connect.

2. Add Users and Group Rules in Azure DevOps Organization

Once we have connected Azure DevOps with Azure AD, we should be able to search and add users and assign a correct set of permissions. To add usera at an organization level follow below steps –

Reasoning – we are adding users and groups and mapping them to correct projects and permissions. Based on these settings, these users and groups will be available at the Projects level and this helps in better control and added to project level security where only the relevant users have access to projects.

How to do it –

• As a user having Administrative permissions in Azure DevOps, login and move to your Azure DevOps Organization.
• Open organization settings and you should see “Users” sub-menu.
• Open the dialog and we should be able to see options to add users. Users are searched from Azure Active Directory since it is now already connected.
• In order to add external users to the DevOps organization, Azure AD Admin must first send invites to these external users to register their emails as Microsoft accounts and get them added as guest users. Once done we should be able to search these guest users in DevOps and add them as well. (Doing vice versa also works but without first adding guest users in Azure AD, they won’t be able to login to Azure DevOps Organization). Users will only be able to login to Azure DevOps if they are registered with Azure AD tenant.
• Have a look at the screenshot below for reference, we have searched and added one user and have given them access to multiple projects as Project Administrators. (Projects are assumed to be already created by Azure DevOps Admin/ Project Collection Administrator which should be simple stuff)

On same lines, we can add Group Users as well and can map multiple users to the group. This can be more manageable when compared to adding users individually.

3. How to add custom groups in Azure DevOps organization

In the above section we created group rules where we added a Azure AD group and users and controlled Project access level. Under Organization Permission settings, we have an option to assign fine grained permissions to default or custom DevOps groups. Permissions are assigned to have just right level of control on the Projects and the underlying services (Boards, Repositories, Pipelines , Test Plans ,Processes). If default Azure DevOps groups are not meeting our needs then we can also create customer groups in this screen and map users to them.

**Groups added here are not from Azure AD but these are a custom set of Groups which can be created.

Reasoning – Navigating to DevOps Organization — Settings — Security — Permissions section, we should see the default set of groups available with Azure DevOps. As an example we have a default group called “Project Administrators” and all users belonging to this group have full control on entire organization which is not something we would like to give to our employees in general. But there may be a need where we want to add employees as Project Administrators but without permission to delete the Builds/Boards/Repositories etc. This is a specific requirement and we can achieve this by adding a new group with correct set of permissions.

How to do it –

• Login to Azure DevOps as an Administrator/Project collection administrator and open organization settings.
• Move to Security–Permissions and this will open Groups/Users dialog.
• Add a new group as shown below – here we are adding a Controlled-Admin with limited admin permissions.
• After adding the group, open it and set its permissions as shown below.
• Map appropriate users to the group in the same section.

4. How Users can Opt-out from receiving Email Notifications for a particular activity in Azure DevOps.

Under Azure DevOps organization, we have global notification settings where it shows the list of all notifications available. As an example, there are notifications for Build success/failure, Pull Request Changes etc. Once Projects are added to this organization, all these notifications are inherited at the project level as well which can be seen under Project Settings as well. In general, no teams would like to get flooded with emails for all kinds of activities in Azure DevOps and would like to keep the notification system simple with a limited set of emails for most important actions and tasks.

If we want to disable a specific notification at a global level then Azure DevOps has an option for it as shown below. This setting disables the notification for all the DevOps projects later added to this Organization which may not be a very flexible approach.

Reasoning – In a project team we have people with different roles like developers, testers, BAs, Product Owners, Release Approver, Project Managers etc. At times, all of them would not like to receive the notifications on day to day development activities like builds/ Pull requests / Test Results etc. If that’s the case then this option can be used for opting out of notification system at a user level. Below we will see notification settings at all levels for more understanding.

How to do it –

Moving to a specific DevOps Project Settings, again there is an option to enable/disable a notifications at each individual team level (Teams are kind of Groups only in DevOps Projects). Based on the number of Teams added to the Project, we can enable/disable notifications at the Team level. In most scenarios, this can work fine. Below we have WebDevelopment Team selected in the breadcrumb section. We can change team and control the notifications behavior for all teams in here.

If we further want fine-grain control at a user level and want to disable a specific notification for an individual user, that can also be done by moving to User Profile section and disabling the notification at an individual level. This wont affect other users in DevOps projects. To achieve this, go to User Profile and open Notifications dialog under it. User profile is available adjacent to Login action.

Open Notifications from here and toggle the state to disable the notification that user want to opt-out for.

5. How to connect third party services in Azure DevOps Organization (Service Connections)

Any build and release pipelines in Azure DevOps project will generally have Build, Test and Deployment tasks but apart from that we also integrate our projects with various third-party products to perform additional activities before a product is pushed to production (or a higher environment). Some of the examples are below

• Testing code quality for Design, architectural issues.
• Checking for any security vulnerabilities in the product/software package.
• Checking for any third party dependencies that have known issues.
• Pushing build & release information to other integrated systems in the organization.
• Deploying Product to Cloud Platform like Azure/AWS/GCP etc.
• Performing Load testing with a third party product.
• Deploying container images in Azure container Registry or DockerHub and many many more.

Reasoning and How to do it –

In order to achieve this, Azure DevOps needs to know about these products and needs to connect to them. This is achieved by first installing the extension provided by these third parties in Azure DevOps organization. These are made available in Visual Studio Market Place. This is followed by adding a Service Connections under individual DevOps Project settings. Most third party products expose their functionality to Azure DevOps by providing their Azure DevOps Tasks in Visual Studio Market Place. You should be able to see Extensions under Organization settings and the option to look for them. Azure DevOps only start showing the Build/Release tasks for these products under Project Pipelines after the extension is installed.

Once extension is installed, we need to create a Service Connection for it under the Azure DevOps Project settings. Service Connections option is available under DevOps Project settings. Clicking it opens a service connection dialog where we can search for the product we want to integrate and connect it. Every product will have its own way to connect to Azure DevOps and details are available with the Extension in Visual Studio Market place. As an example, below it shows Service Connection requirements for connecting to SonarCloud. It needs a token to connect to Azure DevOps and process to generate this token will be available in SonarCoud extension page in VS market place.

Finally under pipelines, we should be able to see SonarCloud tasks and use them as well.

Azure DevOps Project Key Features

1. Summary of things already covered with DevOps Organization.

DevOps Projects inherit Users and their Permissions from DevOps organization settings and users will be made available at Project level according to those permissions. As an example any User or Group added in DevOps organization with Admin access on a Project will become part of Project Administrator default Group in Azure DevOps Project. Below are some of the key features that are already covered with Organization features section above.

Users and Groups Setup

• Users – Under Project Permission settings, we should be able to see users mapped under Project level groups according to the permissions assigned to them in Organization settings. Check above for Organization Settings.
• Groups – We should be able to see default set of Project Groups here. Also Teams added under the project are also shown under this section since technically speaking they are groups as well. We can add a new group under Project if default available groups are not suiting our permission and security requirements and similar use case was explained with Organization Features above. Same applied to Project level as well.

Using Customer Groups at Project Level

• In the above sections we discussed on this where we can add custom groups at Organization and also at Project level to control the permissions for users more precisely. That way we don’t have to rely on default groups available in Azure DevOps. We took an example of having a controlled administrator group with all permissions except deletion of Projects/Builds/repositories etc. Have a look in above sections for more details

How to opt-out of certain notifications at project level

• We can switch off or disable certain notifications at project level under Project Notification Settings. For more details have a look in above sections

How to connect to Third Party products and services

• This is done by adding Service Connections under Project Settings. We took an example of adding Extension for SonarCloud under Organization settings followed by adding Service Connection under the Project. Again have a look in above sections for more details.

How to make add Branch Policies for Azure DevOps Project Repos

Projects are created under Azure DevOps organization and are a parent container for all Azure DevOps Services (Boards-Repos-Artifacts-Pipelines-Test Plans). Just like permissions are set for users to control access and making DevPps resources secured , on same lines there needs to be a check and control on project repositories as well. Repositories hold the project source code and hence is the most critical item to be controlled and made secure.

How to do it –

Repositories are made secured by controlling the access level for users and groups. This is done under Project Repository Settings (Project settings– Repository section) where we control access level and permissions for the available Project Users and Groups. We can narrow down permissions to individual tasks under the repository. Example: Branch/Tag Creation/deletion , Pull Request allowed etc.

Branch Policies – Repositories holds the source code and act as version control system which means that we will have user activities like Pull Requests (in case of Git repository), Managing Branches (in case of both Git and TFVC) and things like settings reviewers of code, direct code commit allowed or not, commit the code only after build succeeds on merged code etc. All of these aspects are related to source code validation and keeping a quality check on our source code repository. These settings are done under Project Repository Settings by enabling and adding Branch Policies. Below are more details.

Enabling Branch Policies is done under Project Repository Settings

Below we have enabled branch policies for all branches (* icon below maps to all present and future branches in the Project repository). We are making a review of code compulsory with a minimum of three reviewers of the code before it can be committed. Also, we have enabled the linking of minimum one work item/task while creating a pull request.

Under same branch policy screen, there is also an option for adding Build validation rule where we set the code commit rule. Below, we are mandating to have a build success check before code can be committed to any branch (in this case this rule will apply to all branches). Since build process is run using Azure pipelines, we need to select the pipeline for validating the build.

Also under the same section, we have an option to automatically add the reviewers for code reviews rather than manually assigning the reviewer while creating pull requests. This can be very handy and entire project team or specific set of team members can be added in reviewer list. Using this approach all these users gets email notification for the Pull requests and provide much better control and proactive notifications.

How to check Build Agent Capabilities

Agent Pool – Build Server – Build Agents – Azure pipelines runs under a context of a build server which can be Microsoft hosted or self hosted. These build servers have build agents which runs the azure pipeline jobs. In case of Microsoft hosted Agent pool we don’t have full control on the build servers capabilities and although it can handle most things but there are limitations in terms of number of parallel jobs they can run, processing power , lack of specific software and features etc. To have complete control , organizations implement their own build servers which can be made available in on-premise as physical or virtual servers or in the cloud as virtual machines. Server Admins have full access to install all necessary softwares for the build process and install build agents in the machine to register it in Agent Pool. Microsoft provides guidance over the process to install build agents for each platform in their documentation. We can also install multiple agents in the same build server. These build servers are registered in Azure DevOps before they can be used in azure pipelines.

Build agent capabilities – once our build machine is ready, build agent tools under it automatically retrieves a lot of information about the machine as name-value pairs. Things that are automatically discovered are machine name, OS and version and information of some of the major software. If a build agent is not showing some capability automatically we can manually add capability as name-value pair as well. Using this approach we can set different capabilities for individual build agents and control the pipeline runs and scope them to specific set of agents. This could be useful if we have many pipelines and applications in the same DevOps Project using same Build machine. In this case, out of the available agent pool we can assign specific capabilities to each agent (or a sub-set of agents) so that each pipeline can use separate set of agents to execute their jobs.

Note – Before running a build, Pipeline checks for the agent capabilities to see if it will be able to meet the builds task requirements or not. If all capabilities are found , only then pipeline uses that agent to run the build.

To check the capabilities of a build agent , go to Project Settings and we should be able to see Agent Pool under Pipeline settings. Select a Pool and under it specific agent and we should be able to see Capabilities tab in there.

Azure Pipelines Key Features

1. Advantage of using YAML based pipelines

The new YAML based approach for pipeline implementation provide much better control to DevOps teams when compared to traditional GUI pipelines.

• Most fundamental of them is the ability to main pipelines as a code in the version control system. Pipelines can themselves be managed in Azure DevOps same or different repository or even in other version control systems. Pipelines define the infrastructure and hence it provides the capability to manage infrastructure as a code. We can reap all benefits of the version control system with things like maintaining pipeline version history, changes management, audit trail and better reuse across projects & teams etc.
• With YAML, Pipeline itself acts as its documentation and we can further add comments in YAML code to explain each step of build.
• Another advantage is a better reuse of common YAML templates where common shareable portions of YAML can be stored separately and then used across DevOps Projects and teams. A similar thing was also possible in GUI pipelines using Task groups but using YAML it works more seamlessly and with a greater control. As an example, with Task Groups. it may not be possible to refer to Task Group from another common DevOps project but with YAML it is possible. This will be explained below.

2. How to create cross-project reference YAML pipelines

As mentioned above, with YAML we can store common reusable stages/jobs/tasks as YAML templates either in the same Project or in a totally separate Project. Keeping them in a completely separate project has an advantage where these can be maintained by a central team and all other project teams can refer to these templates and maintain a common standard. As an example build, test and release tasks for .Net core application remains common for all projects & teams and we can separate this out in a separate YAML job in a separate repository.

Reasoning – Isolation of common templates , maintain common standard across teams and better reuse across Projects in Azure DevOps Organization.

Process to handle it – Create two separate DevOps projects with first containing the repository with only common templates and other containing the actual project with repository and build pipelines. Call the cross project YAML template from the main pipeline.

a. Common Project with Repository only containing templates – its named here as InnerSource and you can see it contains only the templates. (Need to follow Azure DevOps YAML standard to create the templates. Check this link for more YAML schema details). These templates can contain entire build or release stages or a common job or just a specific build/release task. Whats inside the template is not very important here and understanding this capability is more important.

b. Next Step is having a separate actual Project with source code repository – Here Project is named as WebApplicationProject and it has repository with source code. Please ignore the *.yml files present here and they are not being used.

C. Create a YAML pipeline under this Project and call another InnerSource Project’s *.yml files to add the necessary stages/jobs/tasks. These stages/jobs/tasks can contain any common tasks and some of them are mentioned below but opportunities are endless and depend on how artistically we want to leverage Azure DevOps. Some use cases can be –

• .Net Core Application Build – Test – Release grouped together.
• Calling some third party service like SonarCloud or Fortify scan etc.
• Performing a common task like updating build number using some custom behavior.
• Pushing build information to another integrated Release Management system.
• Generating Release Notes using a common template etc.

See below for actual implementation, we first define the resources on which this pipeline is dependent which in this case is InnerSource repository. Finally we call azure-pipeline.yml template available in InnerSource project repository. In this case for demonstration purpose entire build is being handled inside the common template but in most cases we will use this approach for only the common set of tasks or jobs and need to initialize the parameter values before calling the common templates.

Important – if these common *.yml templates are present in the same Project, then we don’t need to define repository dependencies.

3. How to control the execution of tasks in the build pipeline

It is a simple feature but of great importance in azure pipelines. Pipelines contains tasks which run one after another or may be in parallel if they are in different jobs. In most cases, DevOps teams would like to have full control on sequence of tasks and control their flow of execution. As an example Test task should run only after the Build task of .Net application or penetration testing and scan of an application should happen only after it is released in UAT environment etc. This is controlled by defining conditions in the pipelines. Condition can evaluate to true or false and based on condition outcome the task execution can be controlled where it can either be skipped or executed.

Conditions can use built-in Microsoft defined variables or we can also use our own custom variables. Custom variables can be defined in the Variable Groups or even can be defined within the pipeline itself.

For demonstration, we are using SonarCloud task. Below it shows controlling the sonarcloud task which will run only when –

• The previous task has succeeded AND
• Build Reason (Microsoft defined variable) is Pull Request AND
• Pull request-target (again Microsoft defined variable) is for the merge in the main master branch. **See the condition constraint below with the task.

Reasoning and a possible use case – there may be a scenario where a single pipeline runs as part of CICD process as well as with a schedule like over the weekend or nightly basis. One example could be where we want to run security scans every weekend and not on the daily basis to reduce the build time. In this case Build.Reason variable can really help where we can set it to the value of Schedule ie Build.Reason = Schedule so that task only runs if pipeline is running with a schedule or else skip the task. This can provide great control to DevOps teams to use same pipeline more multiple different requirements.

4. List of Important Azure DevOps Extensions we should know

Extensions are installed at the Organization level using Visual Studio Market Place where we find the extension and then install it under Azure DevOps Organization. There are huge number of extensions that are available for Azure DevOps and below are some of the most important once that help extend the Azure DevOps Functionalities and support Projects Delivery. Extensions once installed add their build tasks which can then be used in Azure pipelines under the Projects.

Below are some of the most useful ones and are explained at a high level only. If you want detailed information on these extensions please visit this article.

A. SonarCloud – SonarCloud is a cloud hosted version of SonarQube and this product is used for static code analysis. It scans the source code for Design, architectural, security , code smells and few other quality issues. Post scan it provides a details project report in SonarCloud website with details of each and every file and code areas that needs improvement. This is great way to maintain code quality and keep technical debt at rest and at the same time keeping code compliant with the industry standards and specifications. Before using the task we need to setup and configure project and quality gates in sonarcloud website and connect it to Azure DevOps Project using a Service Connect. (***This is applicable to most DevOps Extensions, but not all)

B. Sonarqube – if we want to use self hosted server based version of SonarQube then we can use this extension. This provide similar set of features as SonarCloud but in this case SonarQube server is first implemented in an enterprise followed by connecting it to Azure DevOps organization. Reports are published in SonarQube server which can then be browsed using Organization’s intranet and SonarQube server URL.

C. OWASP ZAP – this extension is available to scan the code for OWASP web application standards and post scan provides a report in the Azure DevOps Dashboard with the list of issues in the web applications like XSS issues, Framing issues of websites, Missing Http headers and many more. This extensions doesnt need any service connection and data is made available directly in the Azure DevOps dashboard.

D. CredScan – CredScan is an extension from Microsoft and is used for scanning the code for any hidden and hard coded secrets, certificates information or passwords. Post scan it provides details in the Pipeline logs with the file details having these hard coded secrets and we have an option to break the build if we want to. For CredScan to install, we need Microsoft Premier Support subscription and it is not available without the Premier support.

E. Fortify – Fortify is a third party product from Microfocus and provided application security scan capabilities. It can be used for both static as well as dynamic security scans. It covers many industry security standards like OWASP Top 10, PCI compliance and many more. This is one of the most used product when it comes to Security testing of applications and systems. In case of static scans it checks each individual code file and components in the repository and provide online report with details of all issues. Fortify need to first be installed in a server followed by connecting it to Azure DevOps project before using this task in our pipelines.

F. WhiteSource Bolt and Nexus IQ Server – these can be used to scan for any vulnerable in third party open source dependencies we are using in our projects. It can be used to keep a check on open source libraries like JavaScript libraries or NuGet packages. WhiteSource Bolt doesnt need a service connection to work but Nexus IQ server is more advanced product and needs installation on a server followed by connecting it to the project. Both of these products keep their databases updated with list of open source libraries and packages and their known vulnerabilities and use it to scan the repositories and report issues.

G. AzSK – Secured Azure DevOps Toolkit – AzSK is a toolkit developed by Microsoft Devlabs and is made available as an extension in Market place. It can be used to scan our Azure subscriptions and resources to check for any missing or lacking security configurations. After scanning the Azure subscriptions, it generated an excel report with list of all the Azure resources and the security gaps they have. It also provides recommendation and remediation steps ie what to do to mitigate the gaps. AzSK can also automatically remediate the security issues under the Azure subscription depending on its configuration in pipeline task. It consists of powershell modules which are first installed on the build agent and then used to scan through our azure subscriptions.

H. Delivery Plans – This is an extension for Azure Boards and adds a hub in the Azure Boards. It can be used to track and keep a check on the delivery plans for multiple dependent teams. We can see the start and end dates of sprint deliveries of each team and use these insights to plan work better based on cross team dependencies.

I. ReportGenerator – this extension is related to unit testing and testing in general. It is used to generate human readable report for the coverage data generated by various products like Visual Studio, dotcover etc. It can read multiple different coverage data formats and use it to generate a report which can be easily understood by DevOps users. Report is made available in DevOps dashboard screen. It does not need any service connection and work directly with Azure DevOps pipelines.

J. Estimate – this is a great small extension which can be used to estimate story points for agile/scrum user stories. It adds a hub in Azure Boards and provides a voting system where each team member can vote their story points for user stories individually and later data from all developers can be used to come to a conclusion.

K. Contribution Graph – this is another great Azure Boards extension and also adds a hub in Azure boards. Using this we can see each team member’s contribution in the spring delivery. It provides a great way to see the contribution and value added by each DevOps team member visually.

Conclusion

I end this article here and hope it provides some value and insights. I will be pushing more related articles soon. If you want to connect with me or have an opinion for this article and want more information or corrections, do comment and I will be more than happy to support / update.