General ➤ Overview

The Overview section allows you to manage the general properties associated with an organization such as the name of the organization, privacy URL, time zone, and description.

Scroll down in the Overview section to view the two main activities you can perform: changing the owner and deleting the organization, as shown in Figure 2-4.

• Change owner: This option is used to transfer the owner permission to another member of the organization.

• Delete organization: Remove the organization and associated projects. Only the owner can delete the organization along with all artifacts associated with it.

General ➤ Projects

This section lists the projects associated with the organization. In this section, we can create a new project, delete a project, or rename an existing project, as shown in Figure 2-5.

General ➤ Users

Basic users have permission to access all the DevOps components, all the way from boards until the pipeline. This doesn’t mean that access to all projects are allowed. The permission is there, but access is provided based on the access provided in each project at a granular level. Stakeholders have access to boards to view the backlog items, progress, sprint execution, and dashboards. They won’t have access to the code repositories or the build and release pipeline. Visual Studio Subscriber has the same access as a Basic user but with an attached Visual Studio license. You can find details about the permissions and access levels at https://docs.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=azure-devops.

Add a few users as Basic users and a few users as Stakeholders using the Add Users option.

The Add Users option allows us to onboard new team members to the organization with specific permissions, as shown in Figure 2-6. If there is an existing project available, at the time of onboarding, provide the permission to different projects using Azure DevOps groups. Azure DevOps groups are used to group team members and assign specific permission. You can learn more about groups in the section “Security ➤ Permissions.”

In the Users section, you can change the user access levels. This section allows you to reassign a user license to a new user, remove an existing user from the organization, or resend the invite to join the organization. Moreover, the Manage User option allows you to track the overall user permissions.

General ➤ Billing

The Billing section shows the billing of this subscription. To explore the various features of Azure DevOps, a free trial account is configured here. The billing shown in Figure 2-7 corresponds to the free trial account.

General ➤ Auditing

The Auditing section lists the activities performed across different projects in the organization. It also provides an option to export the logs in CSV and JSON formats, as shown in Figure 2-8.

Moreover, the Streams tab allows you to configure new log streams from Azure Event Grid, Splunk, and Azure Monitor Logs. Mainly, streams are used to analyze the production or staging environment logs to identify any potential threats.

General ➤ Global Notifications

The Notifications section lists the default notifications, which can be disabled or enabled for all projects in this organization, as shown in Figure 2-9.

The Subscribers tab shows the notifications based on the users, in other words, what notifications are set for a selected user. The Statistics tab shows the active subscribers and top event initiators and deals with the delivery configuration, as shown in Figure 2-10.

General ➤ Usage

The Usage section shows the dynamic view of the usage of the system in terms of Team Services Through Units (TSTUs).

There are many filters and column selection options available to filter the data in lower levels. Moreover, this report provides an option to save the content in CSV format.

General ➤ Extensions

The Extensions section provides an option to add customized services from the community or other companies. The Extensions section provides an interface to customize Azure DevOps based on your requirements. Also, this option helps you explore the useful community-built services integration. Azure DevOps extensions are available in the Visual Studio Marketplace: https://marketplace.visualstudio.com/azuredevops?utm_source=vstsproduct&utm_medium=L1BrowseMarketplace&targetId=bc12d2e1-b56e-461e-a3eb-1852f2030883.

For example, the SonarQube extension (https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarqube) available in the Marketplace supports the build tasks to integrate the SonarQube code analysis as part of the build steps. We will explore different extensions in later chapters.

The Security option available in this section is important. The organization owner can provide permission for another member to install an extension using this feature. Otherwise, only the organization owner is allowed to install an external extension.

General ➤ Azure Active Directory

Azure AD integration helps map the organization members to the enterprise Azure AD identity. This helps track the activities of internal users.

Security ➤ Policies

Organization-level policies are configured in the Policies section, as shown in Figure 2-11. Project-level policies are explained under the “Project Settings ➤ Repo policies” section.

Security ➤ Permissions

The Permissions section has settings related to organization-level permissions for each group and user. From here, new groups can be configured with specific permissions as well.

You can learn more about permissions and their values in the “Project Settings ➤ General ➤ Permissions” section.

Boards ➤ Process

Understanding the process template is important to defining proper project management. Select a process template to explore this further.

Basic Process Template

The Basic process template provides the basic structure required to map the requirements to the system, as shown in Figure 2-12. Epics capture the business and functional requirements at a high level. Issues track the defects associated with the deliverables, and tasks define the implementation tasks related to the project. The Test Case, Test Plan, and Test Suites types provide facilities to manage the test artifacts properly in the system.

Agile Process Template

In the Agile process template, epics handle the high-level business requirements, whereas a feature defines the functional-level features of the application or product or software. User stories elaborate on the user activities and the expected behavior of the application. Bugs track the defects, whereas issues are challenges in executing the project. Tasks are the implementation tasks associated with a user story. In this template also, the items called Test Plan, Test Suite, and Test Case deal with test management, as shown in Figure 2-13.

Scrum Process Template

In the Scrum process template, epics handle the high-level business requirements, whereas a feature defines the functional-level features of the application or software. Product Backlog Item elaborates on the user activities and the expected behavior of the application. Tasks define the implementation work. Bugs track the defects, whereas impediments are challenges in the execution of the project. In this template also, Test Plan, Test Suite, and Test Case all deal with test management, as shown in Figure 2-14.

CMMI Process Template

In the CMMI process template, epics handle the high-level business requirements, whereas a feature defines the functional-level features of the application or software. Bugs track the defects, whereas issues are challenges in the execution of the project. Change requests are used to track changes in the life cycle. Requirements track the requirements life cycle. Reviews track the review process and results. Risks track the risk mitigation. Tasks define the implementation work. In this template also, Test Plan, Test Suite, and Test Case deals with test management. Figure 2-15 shows the work items associated with the CMMI template.

Customization of the process templates will be covered in the “Process Template Customization” section of this chapter.

Pipelines ➤ Agent Pools

Each agent pool shows the jobs running on the pool, the agents configured against the pool, the owner, and the permissions. We will look at agent pools in Chapter 6.

Pipelines ➤ Settings

The Settings section provides control over configuring global decisions, as shown in Figure 2-16. For example, if the enterprise policy defines the usage of Marketplace tasks are not secure, disable it on the organization level.

Pipelines ➤ Deployment Pools

Deployment pools define the set of target systems that will be used for deployment by a few or all of the projects under this organization. Defining a new deployment pool requires you to configure the target systems using PowerShell commands, which will be explained in detail as part of Chapter 6.

Pipelines ➤ Parallel Jobs

Parallel job execution depends on the agent pool configuration and subscription tier. For a free trial account, the Microsoft hosted agent pool provides ten parallel jobs, which means the build can be configured to execute multiple tasks in parallel. You’ll learn more about the job execution in Chapter 6.

Pipelines ➤ OAuth Configurations

The OAuth Configurations settings allow you to define connections with enterprise subscriptions such as GitHub, GitHub Enterprise, and Bitbucket over OAuth 2.0.

Artifacts ➤ Storage

Artifacts are the executable resulting from a build or the package used for deployment. The “Artifact storage” setting shows the storage used by different artifacts such as the pipeline artifacts, symbols used for debugging, NuGet package feeds, and so on.

This data helps the organization administrators analyze the storage usage and control the costs associated with the organization by configuring the proper retention policies.

General ➤ Overview

The Overview section allows you to reconfigure the project name, description, process template, and visibility. Along with these basic details, it also allows you to add a new project administrator and delete the project.

Based on the project, disable the components that will not be used. For example, some enterprise projects with high security concerns manage the code in local Git repositories instead of Azure DevOps and use the Azure DevOps boards for agile execution and Azure DevOps pipelines for build and release. In the case of a containerized application deployment, the built-in Artifacts component is not used; instead, an external container registry like Azure Container Registry or Docker Image Registry will be used. In this case, project administrator can disable the Artifacts option.

General ➤ Teams

By default, the system provisions a team with the name of the project to manage access to the project, as shown in Figure 2-19. New teams can be provisioned to control the access on the team level, such as the test team having access to the test plans and the stakeholders requiring only read-only access to certain artifacts.

Select an existing team to add new members to the team, as shown in Figure 2-20. Team details such as name, avatar, and description can be modified by navigating to the Settings tab. Also, you can remove any team that is not the default team of the project using the Settings tab.

Creating a New Team

Like a project that has an avatar indicating the project logo or the real spirit of the project, we can have an avatar for each team. Specify the name of the team, a brief description, and add few a members as part of this team, as given in Figure 2-21.

This section will allow you to add the administrator of the project as a member of the team and provide permissions based on the built-in roles. You’ll learn more about the built-in roles in later chapters. The area path is another aspect, as shown in Figure 2-22, that will be covered in subsequent sections.

General ➤ Permissions

End-to-end project execution involves many people with different roles and requirements. A project manager or a business stakeholder will be interested in task completion and how many pending activities there are. At the same time, a developer would concentrate on the source code and associated artifacts, a tester would focus on the test plan and overall functionality, and so on. Group the different team members under different groups to define the required permissions.

As observed in Figure 2-23, the teams are also added as groups. A new group can be provisioned from this section to assign permissions. Select a group to understand the permissions assigned to it.

Permissions are grouped under General, Boards, Analytics, and Test Plan, as shown in Figure 2-24. Based on the need, change the permission value to Allow, Deny, or “Not set.” Changes will be saved immediately and go into effect for the corresponding team members.

The Members tab displays the members belonging to this group. Similarly, the “Member of” tab displays the groups that this group belongs to, as shown in Figure 2-25. By default, every group getting added to the project will be part of the Project Valid Users group. If required, add new groups.

The Settings tab allows you to modify the group image or avatar, name, and description. It also allows you to delete the group.

General ➤ Notifications

The Notifications section provides different built-in notification capabilities. Some notifications are configured by default. For example, when a build completes, members get a notification to their configured emails.

To understand the conditions associated with a notification, select the View option available next to the globe icon, as shown in Figure 2-26.

Selecting the View option opens the configuration of the selected notification; you can define the description of the notification, who will receive the notification, and the filter criteria.

At any time, users can opt out of a notification using the switch key at the end of each notification, as shown in Figure 2-27.

Click “New subscription” to add a new notification to the list. For example, add a new notification for the build failed criteria by selecting Build for Category and “A Build fails” for Template, as shown in Figure 2-28.

Click Next to define the notification criteria. For build fails, we can get the notification to a custom email address like the service group’s ID, as shown in Figure 2-29. Using the Filter option, you can apply the notification configuration to all projects under this organization or to a specific project.

Click Finish to complete the configuration of a new notification, which gets triggered on build fails.

The delivery of each notification can be controlled using the delivery settings, as shown in Figure 2-30. Select one of the notifications and select the Delivery Settings option available on top to reconfigure the delivery options.

General ➤ Service Hooks

Service hooks help to trigger or notify an external system about an internal event. For example, if you configured your build in an external Jenkins system and want to notify the code commits to Jenkins, utilize the service hooks with code push event defined in Azure DevOps.

Clicking “Create subscription” opens the New Service Hooks Subscription dialog with the available integration options, as shown in Figure 2-31. We will look into these integrations later in this book.

General ➤ Dashboards

The Dashboard section allows the project administrators to provide permission to team members to configure dashboards. By default, team members will not have permission to configure a new dashboard or edit or delete a dashboard, as shown in Figure 2-32.

Boards ➤ Project Configuration

In the Project Configuration section, configure the iterations or sprints and areas. Sprints define the duration of each iteration, which can range from one week to four weeks. Based on the agile planning and complexity of the project, a team decides on the sprint duration, called sprint cadence . In scrum, there will be a different release cycle, which may cover one or more sprints. Release cycles are called release cadences . By default, sprints are labeled Sprint 1, Sprint 2, and so on, and this can be changed based on the project requirements, as shown in Figure 2-33.

Iterations can be defined in different levels as well. For example, a sprint with a cadence of four weeks can be further divided into one-week iterations to focus on specific tasks. Also, this can be configured without multilevel iterations, as shown in Figure 2-34.

Areas can be defined in many ways, as shown in Figure 2-35. This can be used for separating the work items related to different teams; it can denote different features, can be different components, can be different layers, and so on.

Areas are used to separate the work, especially the work items in boards and as part of queries. This will be discussed as part of Chapter 3.

Boards ➤ Team Configuration

The team configuration settings related to boards, iterations, areas, and templates for teams. Under the General settings, configure the navigation levels and working days. Also, this allows you to configure how the bugs or defects are treated as part of sprint boards.

The Iterations tab allows you to decide on what iterations this team is going to contribute. Teams such as the design team may be onboarded as part of the initial iterations. Sometimes, performance testers will be onboarded after a few iterations only.

Similarly, the Areas tab supports the team-level configuration of areas, as shown in Figure 2-36. For example, the mobile app development team may require access to the work items related to mobile app area, whereas a UI developer requires access to tasks related to the UI area only.

Boards ➤ GitHub Connections

Even though Azure DevOps provides a full-fledged end-to-end solution for DevOps implementation, enterprises may look to manage the overall DevOps process using multiple tools such as GitHub, GitLab, Jenkins, and so on. GitHub is a popular code repository, which can be integrated with Azure Boards to manage the end-to-end activities.

Once the GitHub credentials or PAT or enterprise configuration is passed, the system will ask to authorize a few permissions to share data between the GitHub account and Azure DevOps.

The GitHub integration now completes and is added to the Azure DevOps settings, as shown in Figure 2-37.

Repos ➤ Repositories

The Repositories section presents the single code project that resides in your Azure DevOps project. By default, one repository is configured at the time of project creation, as shown in Figure 2-38. If you are working with a project consisting of multiple microservices, each service can be configured with a separate repo to handle the codebase separately. Also, granular repos help in defining different build and release pipelines for each of the repos.

Add a new repo to the existing project using the Create button. Repos can use different repository types such as Git or Team Foundation Version Control (TFVC), as shown in Figure 2-39. Git allows you to add a ReadMe file to the blank repo, which explains the usage of the project. This file captures the description and usage of the project.

Also, this dialog allows you to set up the .gitignore file, which explains which file types should be ignored as part of version control. For example, in a C# project, we may not do the version control of the DLLs generated as part of the build.

When it comes to a TFVC-based repo, there’s no need to configure the ReadMe and .gitignore file, as shown in Figure 2-40.

Repo Settings

Select the newly created repo to configure the settings. The Settings tab provides options to disable forking and automatic link creation for commits and related work items, as shown in Figure 2-41.

Repo Policies

Select the Policies tab to set different policies for the repo and branches. Turn on the required policies for the repo to protect the code quality.

The policy in Figure 2-42 restricts commits to team members with emails ending in @org.com and prevents commits from [email protected].

In configuration in Figure 2-43, file size is restricted to 100MB. Files larger than 100MB will be rejected from the commit.

Branch Policies

Branch policies control the policies related to a branch. Every repo is configured with a single branch called master, as shown in Figure 2-44. Based on branching and merging decisions, the project administrator can configure different branches.

Select the branch for configuring the settings, as shown in Figure 2-45. There are four policy setups available for each branch: Branch Policies, Build Validation policies, Status Checks, and Automatically included reviewers.

“Require a minimum number of reviewers” defines the number of reviewers that can approve a pull request and the actions related to the pull request. In Figure 2-46, the policy is configured to have a minimum of two approvers to complete the merge operation. If one of the reviewers selected Wait, the operation still completes due to the setup shown here in the policy.

It is a good practice to link the code changes to one or more work items; this will enable the traceability of the application. Traceability means the identification of code changes related to a specific requirement. It also traces the bugs raised against the requirement and the test cases executed against the code changes and establishes an end-to-end view from requirements to release. Select the Required option under “Check for linked work items” to enforce the linking of a minimum of one work item against the code changes, as shown in Figure 2-47.

The “Check for comment resolution” policy will be discussed after understanding the usage of comments as part of pull requests. Review comments provide an option for collaboration and pass messages to another person about the Git commits.

The next policy to limit the merge types controls the supported merge types between two branches, as shown in Figure 2-48. You’ll learn more about merge types in Chapter 4.

By default, Azure DevOps provides four types of merges.

• Basic merge: This creates a merge commit to the target by pointing to the source and target as parents. This preserves all the history information. When the number branches increase, then the commit history in the target or parent branch is more complex and will be difficult to manage.

• Squash merge: Instead of adding all the commits from the source branch, squash merging takes all the changes and adds them as a single commit to the target branch. This will reduce the commit history in the target or parent branch.

• Rebase and fast-forward: Rebase rewrites the changes from one branch to another without creating any commit.

• Rebase with merge commit: After rebasing the target branch, do a merge commit to complete the merge operation.

Scroll down to view the policy setup related to the build validation, status checks, and automatically included reviewers, as shown in Figure 2-49.

Add a new “Automatically included reviewers” policy to control the pull requests. For example, pull requests to the master should be reviewed by two reviewers to ensure the proper code quality and logic implementation, as shown in Figure 2-50.

Repo Permissions

The repository permissions section displays the permissions against each of the defined groups and users. Also, this section provides an option to configure the permissions related to tags and branches, as shown in Figure 2-51. Different supported permission values are Deny, Allow, and Not set. Deny will deny the specific permission, whereas Allow will explicitly allow the permission. If the value is “Not set,” then it can be overridden by the permissions of a parent group, which will be displayed as Allow (inherited) or Deny (inherited).

Scroll down to view the permission section against the Git repo, as shown in Figure 2-52.

Select a branch to modify the permissions associated with the branch. Similarly, permissions related to the tags can be modified here.

All Repositories: Settings

The Settings section related to all repositories allow you to configure the Gravatar images for external users outside the organization, as shown in Figure 2-53.

All Repositories: Policies

The Policies section under All Repositories allows similar configuration as for repo policies. In addition to the normal policies, this section allows you to protect namespaces associated with all the repositories.

You can add new branch protection using the plus sign available in the “Branch policies” section. See Figure 2-54.

Select the type of protection required for the branch to continue. Once you select the protection type, select different branch policies discussed earlier in the “Branch Policies” section. Users can protect the current and future branches using a pattern such as master, releases/*, dev, etc. The user can either specify the branch name or provide a pattern indicating the branch name. For example, * indicates all branches in the repo.

Pipeline ➤ Agent Pools

Each agent pool shows the jobs running on the pool, agents configured against the pool, owner, and permissions. We will look at agent pools in Chapter 6.

Pipeline ➤ Parallel Jobs

Parallel job configuration was explained in detail as part of organization settings. The project-level settings help you control the usage of agent pools and parallel job availability.

Pipeline ➤ Settings

The Settings section under Pipeline configures the retention policies associated with runs and pipeline. Also, this section provides options to configure a few of the pipeline parameters such as publishing metadata from a pipeline, disabling anonymous access to a status badge API, and so on.

Pipeline ➤ Test Management

The Test Management section deals with the flaky test cases. These are test cases that result in different outcomes for the same set of data and without any code changes. These kinds of test cases may result in developer focus on unnecessary areas. Detecting and fixing flaky test cases reduces the build failures. Configure the different options to detect the flaky test cases in the “Test management” section, as shown in Figure 2-55.

Pipeline ➤ Release Retention

The “Release retention policies” section, as shown in Figure 2-56, provides options to configure the retention of release and release artifacts.

Pipeline ➤ Service Connections

This section presents the connection settings to external systems. If the deployment of the project is in Azure, then define a service connection to the Azure subscription using the various supported mechanisms. The “New service connection” option shows the list of supported external systems including Azure, Chef, GitHub, Jenkin, SSH, and so on. You’ll learn more about services connections and how to configure various connection in Chapter 6.

Pipeline ➤ XAML Build Services

XAML builds are the old build setup based on Windows Workflow Foundation (WWF). This section supports any legacy XAML builds available in your project.

Test ➤ Retention

This section defines the configurations related to the retention of test runs and associated results, as shown in Figure 2-57. Configure the retention period based on the enterprise requirements.