Our Azure DevOps Cloud integration allows you to import pull requests, and associated comments, commits, events, and reviews into Keypup to create unique metrics around these entities and across multiple projects.

Data coming from Azure DevOps can be used to calculate overview metrics such as DORA metrics or to drill down on particular aspects of development, such as retrieving all pull requests currently requiring a peer review.

Our Azure DevOps integration fetches the following entities:

Activity events (e.g., created, closed, assigned, etc.) are fetched for each pull request and exposed in the Activity Events dataset.

These events are also used for the calculation of certain calculated timestamps, such as assigned_at and last_assigned_at.

This entity is exposed as a dataset on Keypup. Comments can be used to create a feed of updates or to create activity metrics.

E.g., Recover and display comments of all recently merged pull requests.

This entity is exposed as a dataset on Keypup. Only commits attached to pull requests are retrieved. Standalone commits pushed directly to branches are not available on Keypup at this stage.

Commits can be used to create activity feeds, release notes, or metrics.

E.g., Display the commit message of all commits merged into main/master over the last two weeks.

Coming soon. Importing work items is part of our short-term roadmap.

This entity is exposed on Keypup as part of the Issues & Pull Requests dataset. It can be used to create activity metrics.

E.g., Calculate a refactoring ratio, which is the number of lines of code deleted divided by the number of lines of code added.

It can also be used to create simpler listings:

E.g., List of open pull requests with less than 30 lines of code changed (“small” pull requests).

Limitations

Updating the description or the labels/tags of a pull request does not trigger an update event from Azure DevOps. Updating those fields will not trigger a webhook and will not update the updated_at field.

This entity is used to populate the build status field on the Issues & Pull Requests dataset. It is only applicable to pull requests. It can be used to filter pull requests in metrics and listings.

E.g., Retrieve the list of pull requests that were merged with a failed build.

This entity is exposed as the Reviews dataset. It is also used to populate the review_state and required_approval_remaining_count fields on the Issues & Pull Requests dataset. It can be used to create metrics or listings.

E.g., Compare the proportion of approved reviews vs rejections.

E.g,. Create a feed of review comments.

Updates from Azure DevOps are generally received in real-time via webhooks.

On top of real-time webhook updates, Keypup does long polling every hour.

Updating the description or the labels/tags of a pull request does not trigger an update event from Azure DevOps. Those updates are always picked up via long polling.

In the context of Azure DevOps, Keypup fetches the repository code to compute diff statistics (lines added, lines removed, lines changed) for pull requests and their associated commits.
​

This is necessary because the Azure DevOps API does not expose diff statistics on its API, making it impossible to calculate these values without fetching the code.
​

You can contact our support team prior to importing your Azure DevOps projects to disable the fetching of the code. If you choose to disable this feature, please be aware that pull requests and commits will not have diff stats information (line changed, lines added, lines removed) on Keypup.
​

We take the security of your code very seriously. Here are the measures we have in place:

Keypup uses context inference and link detection to automatically enrich your data, add new fields, and simplify your reporting. Context inference can be improved by linking pull requests to issues using auto-closing keywords.

Linking issues to pull requests allows us to populate and improve the following fields:

Issues & Pull Requests > Due on: When a pull request is linked to one or more issues, Keypup automatically infers the due date by taking the soonest of all due dates across the pull request and its related issues.

Issues & Pull Requests > Resolution State: This field is only applicable to issues. It infers the implementation status of the issue by looking at the associated pull requests. The field can have the following values:

These two fields can be used to refine your metrics and/or drill down on specific data. E.g., Retrieve the list of overdue issues that are not currently being resolved by a pull request.

There are several ways to reference an issue from a pull request.

Option 1: Via the pull request title

To reference a JIRA issue, such as PROJ-123, you can set your pull request title to:

Option 2: Via the pull request body or a commit message

To do so, the reference or URL of your issue must be prefixed by an auto-closing keyword, such as fixes, resolves or closes - for instance:

Read this article to learn more about using smart commits

Read this article to learn more about referencing issues in your development work