Teilen über

Cross-service overview

  • Artikel

TFS 2018

Azure DevOps lets you connect to and collaborate across its core services. You can use various features to link and track your devops tasks across Azure Boards, Azure Repos, Azure Pipelines, and Azure Test Plans. This article shows you options for how to use the cross-service integration of Azure DevOps to improve your workflow and productivity.

Links to more information:

Collaboration across Azure DevOps

The following table summarizes some of the features that help you work with your team and other teams.

Feature

Description

@mentions (add to discussions and comments)

You can @mention a team member or an entire team within a work item form discussion or the comment section of a commit, pull request, or changeset.

#ID (link to a work item)

To support end-to-end traceability, you can link to work items from commits, pull requests, and changesets.

Teams

Each team gets access to a suite of Agile tools and team assets. These tools let teams work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to support how they work. For quick navigation, they can favorite repositories, pipelines, and test plans.

Set up alerts

Configure or opt out of personal, team, project, or organization-level alerts. Subscribe to email alerts when changes occur to work items, code reviews, pull requests, source control files, builds and more.

Share summaries by email

Azure Boards - Azure Repos

You can link code changes to user stories and features with different link types. For Git, use Branch, Commit, Pull Request, or Tag. For TFVC, use Changeset or Versioned Item.

Conceptual image of link types that link work items to Azure Repos objects.

The following table summarizes the integration points between Azure Boards and Azure Repos.

Feature

Description

Drive Git development from work item(s)

You can initiate a Git branch or link to Git commits or pull requests and drive your Git development cycle for a work item from within the work item form.

Automatically link and transition work items with Git commits

For a Git repository, you can turn on or off the following options:

  • Close work items with mentions in commit comments. - Remember user choices for completing work items with pull requests.
  • Link work items from commit comments. You can also automate linking from commits or pull requests in repo settings.
  • Commit mention linking: Turn on to link commits to work items with #WorkItemID in commit messages. Turn off when you push a repo from a different account or service. Azure DevOps automatically turns off this feature when you import a repo.
  • Commit mention work item resolution: Turn on to close work items with Fixes #WorkItemID in commits.
  • Work item transition preferences: On by default, it remembers each user’s option to complete linked work items with pull requests. You can turn this feature off to discourage users from completing work items with pull requests. When it's off, users have to choose to complete work items for each pull request.

Check for linked work items in a Git branch

Encourage traceability by checking for linked work items on pull requests.

Auto complete work items with pull requests

When you link a work item to a pull request (PR), you can automatically complete those work items when you successfully complete the PR. The system defaults to your selection for future PRs.

View list of code objects a single work item is linked to

You can link work items to code changes, builds, and releases—providing an audit trail of how a feature has been developed

Query for external links

You can query for work items that contain links to branches, commits, pull requests or tags.

Configure branch policies to support work tracking

To ensure that changes to a branch have links to work items, you configure the branch policy for a Git repository in repo settings. Turn on the Check for linked work items option. Choose Required to mandate all pull requests have at least one linked work item in order to be completed. Choose Optional to allow pull requests without linked work items, but warn about it.

Azure Boards - Azure Pipelines

The following table summarizes the integration points between Azure Boards and Azure Pipelines. Several features provide support for end-to-end traceability as user stories and features move through the development cycle. As with Azure Repos, you can link work items to pipeline objects with the following link types: Build, Integrated in build, and Integrated in release.

Conceptual image of link types that link work items to Azure Pipelines objects.

Feature

Description

Manually link work items to builds.

Link work items to builds in the same project within the organization or collection.

Set integration option to automatically create Integrated in build links to work items linked to a branch, commit, or pull request associated with a pipeline.

Required to populate the Development control with Integrated in build links. The work items or commits that are part of a release are computed from the versions of artifacts. For example, each build in Azure Pipelines is associated with a set of work items and commits. For more information, see Configure pipelines to support integration.

View list of build or release objects a single work item is linked to

You can link work items to builds and releases—providing an audit trail of how a feature has been built and deployed.

Query for external links.

You can query for work items that contain external links.

Azure Repos - Azure Pipelines

Azure Pipelines provides support for building code stored in Azure Repos, either a Git or Team Foundation Version Control (TFVC) repository. Other repositories that Azure Pipelines supports are listed in Supported source repositories.

The following table summarizes the integration features between Azure Repos and Azure Pipelines.

Feature

Description

Report deployment status

Indicates the status of a deployment on the Files, Commits, and Branches pages for Git repositories. This feature improves the traceability from code commit to deployment. You can configure the release environments to report deployment status.

Code coverage

Publish and review code coverage results that indicate the proportion of your project's code that is actually being tested.

Azure Boards - Azure Repos - Azure Test Plans

Several collaboration scenarios are supported through Azure Boards work item types. As with other work item types, you can use managed queries and the Azure DevOps search function to find and list work items.

Note

Several of these work item types—such as Feedback Request, Code Review Request, Shared Steps, and Shared Parameters—are designed to be created through a specific tool or form. They aren't meant to be created manually. Therefore, they are added to the Hidden Types category. Work item types that are added to the Hidden Types category don't appear in the menus used to add work items.

Also, for the Inherited process model, you can only customize the following work item types: Test Plan, Test Suite, Test Case.

Scenario

Work item type

Description

Request code review

Code Review Request

Tracks information entered into the TFVC New Code Review form. For more information, see Get your code reviewed with Visual Studio.

Provide code review

Code Review Response

Tracks review comments provided by code reviewers in response to a code review request.

Request feedback

Feedback Request

Tracks information entered into a request feedback form. Use the following forms to initiate a feedback request.

Provide feedback

Feedback Review

Lets stakeholders provide feedback based on requests for feedback or by volunteering feedback using the Microsoft Test & Feedback Marketplace extension.

Manual testing

Test Plan

Groups one or more test suites and individual test cases together. Test plans include static test suites, requirement-based suites, and query-based suites. To get started, see Create test plans and test suites.

Manual testing

Test Suite

Groups one or more test cases into separate testing scenarios within a single test plan. Grouping test cases makes it easier to see which scenarios are complete.

Manual testing

Test Case

Defines steps used to validate individual parts of your code to ensure your code works correctly, has no errors, and meets business and customer requirements. You can add individual test cases to a test plan without creating a test suite. More than one test suite or test plan can refer to a test case. You can effectively reuse test cases without having to copy or clone them for each suite or plan.

Manual testing

Shared Steps

Enables sharing steps across several test cases.

Manual testing

Shared Parameters

Enables repeating the same test cases with different data.

Test work item types

Work item types that support the test experience are linked together using the link types shown in the following image. These include Tested By/Tests, Test Cases/Shared Steps, and Reference By/References.

Screenshot of the Test management work item types.

You can use the web portal to see the test cases that are defined for a test suite, and the test suites that are defined for a test plan. But, there's no specific link type that connects these objects to each other.

Track bugs

The Bug work item type supports the following integrations that you should be aware of when you're tracking bugs.

Scenario

Description

Create a bug from a testing tool

You can add a bug from Test Runner or the Test & Feedback extension. For more information, see Define, capture, triage, and manage bugs.

Create inline tests linked to bugs or user stories

When your team tracks bugs as requirements, you can use the Kanban board to add tests to verify bug fixes or user stories.

Track build information with bugs

The Bug work item form contains System Info, Found in Build, and Integrated in Build, which support tracking code defects found and resolved within pipeline builds. For more information, see Query based on build and test integration fields.

Dashboards and reporting

Dashboards provide an easy way to monitor progress and status. Teams can add configurable widgets to support their goals. SQL Server reports provide other monitoring capabilities.

You can add the following built-in widgets to your dashboard. They're organized under the service they support. You might find more widgets from the Azure DevOps Marketplace.

Widgets are annotated as follows:

  • Build: Widget derives data for a selected build pipeline
  • Release: Widget derives data for a selected release pipeline
  • Team: Widget is scoped to a single team
  • User: Widget is scoped to the signed in user account

Work

Code

Build & Release

Test

Information and links

Automation and connectors

Microsoft products support automation or integration with several other applications and services. For more information, see the following articles.