Azure DevOps helps developers, infrastructure, operations, and PM teams communicate better and deliver consistent and reliable solutions by combining a set of features such as Azure Boards, repos, and pipelines, and all those features together to deliver an end-to-end solution to build your application, infrastructure, and control the progress of any given project from a single pane of glass. In this two-part series, we are going to create customized work items and take advantage of the customization available in the product to shape our backlog. The goal is to provide a better experience by customizing Azure DevOps work items and use them in our Azure Boards to control and track your projects.
Customizing Azure DevOps work items: Our scenario
Let us imagine that our team is responsible for modernizing some applications on-premises and provisioning them in Microsoft Azure. We will be using Azure DevOps for everything — to organize the project itself, infrastructure-as-a-code (IaaC), documentation (wiki), and consistent deployment (using pipelines to multiple environments).
Our team is responsible for evaluating new applications in Azure. That process comprises network evaluation and the application itself through a series of interviews and provision the infrastructure-as-a-code later on.
When we create a new project, we can define the process. By default, we have Agile, Basic, CMMI, and Scrum. They provide a good foundation, but Azure DevOps allows an exceptional level of customization to facilitate a project to focus on what is required instead of looking at the standard interface.
We are going to create a new project called AP6Industries Cloud, but first, we will create our Azure DevOps work items process to accommodate all our customizations for our upcoming project.
In the Azure DevOps portal, click on Organization Settings located on the bottom left corner, and then click on Processes.
In the new window, label the new process (we will use AP6Industries Cloud Agile Process) and provide a description. Click on Create Process.
When creating a new project, we will have the new process that we have just created as an option in the work item process, as depicted in the image below. For now, it is precisely a copy of the default Agile process. However, we will work on modifying our process to accommodate our new project.
Customizing a process
Our initial goal is to create a couple of work items to address the network and application requirements of our project. We will need to create new customized work items.
To create a new work item, click on Organization settings, Processes, and click on the new process that we have just created. A new page on the right side will give all the objects within that given process, which are work item types, backlog levels, and projects.
The Agile process default work items will be displayed. Click on New work item type.
In the new dialogue box, assign a name for the new work item type and description. We can also define an icon and color that will be used for this work item. We will call it Network Requirements. Click on Create.
The new page will have the default fields in a new work item. The first step is to configure groups, which are areas in a tab. We are going to configure a new one called Virtual Network Information, and we will place that in the middle section, as depicted in the image below.
Now that we have an area to place our fields, we can create our first field, by clicking on Add a field.
The new wizard is comprised of three tabs: definition, options, and layout. We will create the first field to define the virtual network that our future application will be configured, and we can select the type of the field (text — simple or multiple lines — numeric, Boolean, date, and so forth).
In the Options tab, we can force the user to add that information and even provide a default value, and that is handy when you have a standard for the vast majority of the application, and some exceptions are allowed.
In the Layout tab, we can take advantage of the groups already created to place our new fields.
Keep in mind that when selecting text (multiple lines), Azure DevOps will create a group automatically. We can’t assign it to an existing group.
The ideal scenario is to understand you want to accomplish the outcome of the process to define the work item that we are creating.
In our example, we need to define some key areas to be addressed by a meeting/interview with the application owner. We started with the following items, and we could’ve added load balancer, application gateways, and any other required information based on your design.
- Virtual network name
- Number of subnets (integer)
- Subnet (Web Tier) Name
- Subnet (application tier) name
- Subnet (database tier) name
- Network security group
- Meeting summary area
- Application security group details
- Network security group details
We can use the same page to hide items (we have done that for deployments and links). We can add more pages (tabs) to the work item when more information is required.
Azure DevOps work items: More to come in Part 2
The goal of this first article was to demonstrate how to create customized work items in Azure DevOps. Following the same logic, we should create a work item for the application type. In this new work item, we should have all the information about the application that we are going to incorporate in our project. We should add some information related to the application and the business, some fields to keep in mind: application owner, cost center, application description, SLA, RTO/RPO, disaster recovery, and so forth.
In our next article, we are going to see how the new work items interact with the existing project.
Featured image: Shutterstock
More Azure DevOps articles
- Using Azure DevOps Repos in your Azure Cloud Shell
- Azure DevOps and IaC: Brainstorming practices and processes
- Managing Azure Key Vault access and secrets from DevOps pipeline
- Azure DevOps tips and tricks: Using built-in features
- Azure DevOps service connections: How to set them up and use them