Connect Azure Repos with DevRev, and ensure your work stays in sync between the two systems, such that issues and statuses are always real-time and driven by code activity. Azure Repos for DevRev is a snap-in that has been used by several organizations, and ties DevRev issues closely with Git activities, eliminating the need for humans to manage issues.
Why should you un-manage your work? You should use this snap-in if you want to reduce work about work. Let machines manage issues, including creating and updating statuses, so developers can focus on work that matters. You'll resonate with this if you have ever:
- Delivered a hotfix and realized you never had an issue to track it
- Wasted time just updating your team on the status of an issue
- Or just felt that creating and managing issues is a distraction
If your team's best practice is to link your Azure Repos activity to an existing issue-ID during branch creation, commits, and PRs, then this automation will honor that and enable an Azure Repos-driven issue state, without auto-creating issues. We can link your DevRev issue to Azure Repos activity through mention of issue-ID in branches, commits, and PRs.
However, if you choose to work in Azure Repos and never created or linked an issue, you shouldn't have to worry. This automation will automatically create issues that track all associated commits, branches, and pull requests. The auto-created issue is enriched with PR descriptions and related Azure Repos events. The status of these issues is driven by Azure Repos activity, and the issues will auto-transition through stages, from In Development to In Review and Closed. Your work is always accounted for, and more importantly, your team members have visibility and know what you have been up to, resulting in fewer interruptions.
How it works
To enable Azure Repos for DevRev, click on Install and we will walk you through a few simple steps, including connecting with Azure Repos. You will have a default set of configuration settings and the option to further personalize this automation. Learn more about the features in this automation.
Features
This automation is powerful and has several configurable features. Upon installing this snap-in, you'll receive tried-and-tested default settings, with the flexibility to customize further as needed.
Automatic status updates
You can associate Azure Repos commits, branches, and pull requests with the DevRev issue they correspond to. Doing so allows you to see Azure Repos activity in the corresponding DevRev issue and to act on those events, allowing you to automate away your manual tasks. Mention DevRev issues in Azure Repos, and route the relevant Azure Repos events to this issue. They can be mentioned either as display IDs (ISS-34
) or object IDs (issue:34
), case insensitively. A DevRev issue can be mentioned in branch names, commit messages, or PR titles.
Autocreate issues from Azure Repos branch
If you do not explicitly associate your DevRev issue to Azure Repos branches, commits, or PRs, then we can auto create your issues so you have an account of all your Azure Repos activity. This feature automatically creates an issue when a new branch is created and tracks all associated commits and pull requests on this issue. The auto-created issues will move status based on Git activity, transitioning to In Development based on branch and commit activity, and In Review when PRs are created and merged. If desired, when PRs are merged, you can personalize the automation to move the issue to Closed status. However, this template by default will keep the issue in an open state.
Autocreate issues from Azure Repos PRs
You can choose to automatically create issues when a new PR is created, and it is not linked to an existing DevRev Issue. The behavior is similar to how issues are auto-created with new branches. The auto-created issues will move status based on Git activity, and events are posted on the DevRev issue timeline. If desired, when PRs are merged, you can personalize the automation to move the issue to Closed status. However, this automation by default will keep the issue in an open state.
Issues autocreated from Azure Repos branches or PRs are called autonomous issues. They have the tag autonomous
.
Attribute part to autonomous work
This automation will infer the part from a repository if possible. If not, the issue is created with a specified default part. You can configure the default part while setting up this snap-in. Every issue on DevRev must have a part attribution.
Enrich autonomous work descriptions
Enrich autonomous issues with information derived from Azure Repos PR events. The title and description of an auto-created issue are enriched with the PR data. When a new Azure Repos PR is opened or edited, then the related autonomous issue description is updated with the latest PR description. If the user has removed the auto-generated text, then the automation will no longer update the description from PRs. Similarly, autonomous work titles are updated with the PR title if the user has not already updated it.
Link autonomous work with related issue
Create a parent-child link between the work-items mentioned in the PR body and the autonomous issues tagged with the branch/PR. When a new Azure Repos PR is opened/edited, for all the autonomous tagged work items (by branch/PR), automatically make the issues mentioned in the PR as parents.
Automatically close autonomous work
Autonomous work gets closed when its related PR is merged. However, if there is no PR activity on this work, then the autonomous work is closed after a configurable period.
Automatic PR reminders
When a pull request is inactive for more than a specified number of days, then this automation will post a message in all related DevRev issues. You'll need to link your Azure Repos pull request to a DevRev issue to enable these reminders. There are several ways to link your Azure Repos pull requests to DevRev Issues. You can do so by mentioning the DevRev issue ID in pull request titles or bodies, or mention it in the branch name or commit message. Reminders are also posted for issues created autonomously.
You can choose to set up the inactive period in number of days through the max_inactive_days
setting.