Port remaining SONAR space docs

1 files changed, 12 insertions, 12 deletions

diff --git a/server/sonar-docs/src/pages/analysis/pull-request.md b/server/sonar-docs/src/pages/analysis/pull-request.md
index 4e17d90c01d..50c85a98307 100644
--- a/server/sonar-docs/src/pages/analysis/pull-request.md
+++ b/server/sonar-docs/src/pages/analysis/pull-request.md
@@ -12,24 +12,24 @@ _Pull Request analysis is available as part of [Developer Edition](https://redir
 
 Pull Request analysis allows you to:
 
-* see your Pull Request (PR) analysis results in the SonarQube UI and see the green or red status to highlight the existence of open issues.
-* automatically decorate your PRs with SonarQube issues in your SCM provider's interface. 
+* see your Pull Request (PR) analysis results in the {instance} UI and see the green or red status to highlight the existence of open issues.
+* automatically decorate your PRs with {instance} issues in your SCM provider's interface. 
 
-PRs are visible in SonarQube from the "branches and pull requests" dropdown menu of your project.
+PRs are visible in {instance} from the "branches and pull requests" dropdown menu of your project.
 
-When PR decoration is enabled, SonarQube publishes the status of the analysis (Quality Gate) on the PR.
+When PR decoration is enabled, {instance} publishes the status of the analysis (Quality Gate) on the PR.
 
-When "Confirm", "Resolved as False Positive" or "Won't Fix" actions are performed on issues in SonarQube UI, the status of the PR is updated accordingly. This means, if you want to get a green status on the PR, you can either fix the issues for real or "Confirm", "Resolved as False Positive" or "Won't Fix" any remaining issues available on the PR.
+When "Confirm", "Resolved as False Positive" or "Won't Fix" actions are performed on issues in {instance} UI, the status of the PR is updated accordingly. This means, if you want to get a green status on the PR, you can either fix the issues for real or "Confirm", "Resolved as False Positive" or "Won't Fix" any remaining issues available on the PR.
 
-PR analyses on SonarQube are deleted automatically after 30 days with no analysis. This can be updated in **Configuration > General > Number of days before purging inactive short living branches**. 
+PR analyses on {instance} are deleted automatically after 30 days with no analysis. This can be updated in **Configuration > General > Number of days before purging inactive short living branches**. 
 
 <!-- sonarcloud -->
-## Integrations for GitHub, Bitbucket Cloud and VSTS
-If your repositories are hosted on GitHub, Bitbucket Cloud or VSTS, check out first the dedicated Integrations for: [BitBucketCloud](/integrations/bitbucketcloud/), [GitHub](/integrations/github/), and [VSTS](/integrations/vsts/). Chances are that you do not need to read this page further since those integrations handle the configuration and analysis parameters for you.
+## Integrations for GitHub, Bitbucket Cloud and Azure DevOps
+If your repositories are hosted on GitHub, Bitbucket Cloud or Azure DevOps, check out first the dedicated Integrations for: [BitBucketCloud](/integrations/bitbucketcloud/), [GitHub](/integrations/github/), and [Azure DevOps](/integrations/vsts/). Chances are that you do not need to read this page further since those integrations handle the configuration and analysis parameters for you.
 <!-- /sonarcloud -->
 
 ## Analysis Parameters
-### Pull Request Analysis in SonarQube
+### Pull Request Analysis in {instance}
 These parameters enable PR analysis:
 
 | Parameter Name        | Description |
@@ -46,14 +46,14 @@ To activate PR decoration, you need to:
 * feed some specific parameters (GitHub only)
 
 #### Authentication Token
-The first thing to configure is the authentication token that will be used by SonarQube to decorate the PRs. This can be configured in **Administration > Pull Requests**. The field to configure depends on the provider.
+The first thing to configure is the authentication token that will be used by {instance} to decorate the PRs. This can be configured in **Administration > Pull Requests**. The field to configure depends on the provider.
 
-For GitHub Enterprise or GitHub.com, you need to configure the **Authentication token** field. For VSTS/TFS, it's the **Personal access token**.
+For GitHub Enterprise or GitHub.com, you need to configure the **Authentication token** field. For Azure DevOps, it's the **Personal access token**.
 
 #### Pull Request Provider
 | Parameter Name        | Description |
 | --------------------- | ------------------ |
-| `sonar.pullrequest.provider` | `github` or `vsts` or `bitbucketcloud`<br/> This is the name of the system managing your PR. In VSTS/TFS, when the Analyzing with SonarQube Extension for VSTS-TFS is used, `sonar.pullrequest.provider` is automatically populated with "vsts". Same on GitHub if you are using the Travis CI Add-on, and on Bitbucket Cloud if you are building with Bitbucket Pipelines.|
+| `sonar.pullrequest.provider` | `github` or `vsts` or `bitbucketcloud`<br/> This is the name of the system managing your PR. In Azure DevOps, when the {instance} Extension for Azure DevOps is used, `sonar.pullrequest.provider` is automatically populated with "vsts". Same on GitHub if you are using the Travis CI Add-on, and on Bitbucket Cloud if you are building with Bitbucket Pipelines.|
 
 #### GitHub Parameters
 | Parameter Name        | Description |