Cross-service overview

Description

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.

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

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.

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.

• Email a list of work items
• Email query items
• Send release summaries by email

Description

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.

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.

Encourage traceability by checking for linked work items on 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.

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

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

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.

Description

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

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.

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

You can query for work items that contain external links.

Description

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.

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

Description

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

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

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

• Request stakeholder feedback
• Get feedback.

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

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.

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.

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.

Enables sharing steps across several test cases.

Enables repeating the same test cases with different data.

Description

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

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

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.