Author avatar

Ronika Mehta

Associating Work Items to Code in Azure DevOps

Ronika Mehta

  • Nov 15, 2020
  • 4 Min read
  • 133 Views
  • Nov 15, 2020
  • 4 Min read
  • 133 Views
Security
General Security Principles
Security Principles
General Security Principles

Introduction

If you’re an engineer working with Azure DevOps (formerly known as VSTS), Team Foundation Version Control (TFVC), or GitHub, then you’re mostly using some form of branching mechanism to isolate your work. You probably aware of different work item types such as bug, task, user-story, feature to track your development efforts using any of the Agile tools in your software projects. Azure DevOps has some great features that can make it easier for you to track the relationship between your code and work.

To do so, you can create a pull request to merge your code to the master branch, and a developer needs to follow few steps such as providing a comment or summary and associating work items to the pull request.

This guide describes the process of associating work items to code and some common obstacles to overcome.

Associate Work Items to Code

Until recently, the best way to keep items related was to link commits to work items using a #ID mention in the commit message. This approach had many issues, including:

  • Teams were unable to query commits based on work items.
  • Teams were unable to identify how many changes went in with an individual user-story or feature.

To help software industries overcome such issues, Azure DevOps (VSTS), GitHub, and many other tools have introduced a new feature for associating work items along with code. This feature gives you better traceability, help you manage dependencies, etc.

Let’s learn about the end-to-end process of associating work items to code using the Azure DevOps (VSTS) tool.

Create a Feature Branch for Your Work

Let’s start at the beginning. As a developer, you have been assigned some work with a specific scope of user story requirements. To create a new feature branch, click on New Local Branch From, as shown in the figure below.

New local branch from option

Once the branch is created and ready for development, check out the remote branch before you start working. You can check out the branch through the command line.

Checkout branch

Now, after you've completed all changes related to the assigned user story, create a pull request and associate work items so that your code gets merged to the master branch.

The next section will explain how to do this.

Create a Pull Request

To create a pull request, navigate to the Repos > Pull Requests section, as shown in the figure below.

Pull requests

Click on the New pull request button and select the feature branch that needs to be merged to the master. Once you provide a description of the pull request, including the pull request’s title, the next step is to associate work items to the pull request, as shown in the figure below.

New pull request

Pull request template

Click on Work Items to link drop down, as shown in the figure below. You should link an appropriatetask or bug or user story to the pull request by selecting work items from the drop down or by inserting a valid work item's ID.

Work items to link

Once all the required steps are done, you can submit the pull request to reviewers.

Conclusion

In this guide, you’ve learned about creating a feature branch, creating a pull request, and associating work items to the created pull request.

In general, doing this helps the software development project team to leverage several benefits:

  • Finding commits based on a given user-story, feature, task, or bug, etc.
  • Identifying commit detail easily in the future
  • Easily tracking related test cases, WiKi documentation, etc.
  • Doing better impact analysis based on a pull request and associated work items

To further build on this guide, a team can set up various branch policies so that developers are forced to associate work items to pull requests. Thanks for reading.

4