To set up the import of Azure DevOps repositories:
-1. Set your global settings
+1. Set your global DevOps Platform settings
2. Add a personal access token for importing repositories
### Setting your global settings
-To import your Azure DevOps repositories into SonarQube, you need to first set your global SonarQube settings. Navigate to **Administration > Configuration > General Settings > ALM Integrations**, select the **Azure DevOps** tab, and click the **Create configuration** button. Specify the following settings:
+To import your Azure DevOps repositories into SonarQube, you need to first set your global SonarQube settings. Navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations**, select the **Azure DevOps** tab, and click the **Create configuration** button. Specify the following settings:
- **Configuration Name** (Enterprise and Data Center Edition only) – The name used to identify your Azure DevOps configuration at the project level. Use something succinct and easily recognizable.
- **Azure DevOps collection/organization URL** – If you are using Azure DevOps Server, provide your full Azure DevOps collection URL. For example, `https://ado.your-company.com/DefaultCollection`. If you are using Azure DevOps Services, provide your full Azure DevOps organization URL. For example, `https://dev.azure.com/your_organization`.
| Because of the nature of a mono repository, SonarQube scanners might read all project names of your mono repository as identical. To avoid having multiple projects with the same name, you need to pass the `sonar.projectName` parameter to the scanner. For example, if you're using the Maven scanner, you would pass `mvn sonar:sonar -Dsonar.projectName=YourProjectName`.
[[collapse]]
-| ## Configuring multiple ALM instances
-| SonarQube can report your Quality Gate status to multiple ALM instances. To do this, you need to create a configuration for each ALM instance and assign that configuration to the appropriate projects.
+| ## Configuring multiple DevOps Platform instances
+| SonarQube can report your Quality Gate status to multiple DevOps Platform instances. To do this, you need to create a configuration for each DevOps Platform instance and assign that configuration to the appropriate projects.
|
-| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM.
+| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each DevOps Platform.
|
-| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
+| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each DevOps Platform. If you have multiple configurations of the same DevOps Platform connected to SonarQube, you have to create projects manually.
[[collapse]]
| ## Linking issues
Setting up the import of BitBucket Cloud repositories into SonarQube allows you to easily create SonarQube projects from your Bitbucket Cloud repositories. If you're using Developer Edition or above, this is also the first step in adding pull request decoration.
[[info]]
-| To import your Bitbucket repositories into SonarQube, you can only have one global configuration of Bitbucket, including Bitbucket Server and Bitbucket Cloud. See the **Configuring multiple ALM instances** section below for more information.
+| To import your Bitbucket repositories into SonarQube, you can only have one global configuration of Bitbucket, including Bitbucket Server and Bitbucket Cloud. See the **Configuring multiple DevOps Platform instances** section below for more information.
To set up the import of BitBucket Cloud repositories:
1. Create an OAuth consumer.
-1. Set your global ALM integration settings.
+1. Set your global DevOps Platform integration settings.
1. Add your Bitbucket username and an app password.
### Creating your OAuth consumer
- **This is a private consumer** – Your OAuth consumer needs to be private. Make sure this check box is selected.
- **Permissions** – Grant **Read** access for the **Pull requests** permission.
-### Setting your global ALM Integration settings
-To set your global ALM Integration settings, navigate to **Administration > ALM Integrations**, select the **Bitbucket** tab, and select **Bitbucket Cloud** as the variant you want to configure. From here, specify the following settings:
+### Setting your global DevOps Platform Integration settings
+To set your global DevOps Platform Integration settings, navigate to **Administration > DevOps Platform Integrations**, select the **Bitbucket** tab, and select **Bitbucket Cloud** as the variant you want to configure. From here, specify the following settings:
- **Configuration Name** (Enterprise and Data Center Edition only) – The name used to identify your Bitbucket Cloud configuration at the project level. Use something succinct and easily recognizable.
- **Workspace ID** – The workspace ID is part of your bitbucket cloud URL `https://bitbucket.org/{WORKSPACE-ID}/{repository-slug}`
| Because of the nature of a mono repository, SonarQube scanners might read all project names of your mono repository as identical. To avoid having multiple projects with the same name, you need to pass the `sonar.projectName` parameter to the scanner. For example, if you're using the Maven scanner, you would pass `mvn sonar:sonar -Dsonar.projectName=YourProjectName`.
[[collapse]]
-| ## Configuring multiple ALM instances
-| SonarQube can report your Quality Gate status to multiple ALM instances. To do this, you need to create a configuration for each ALM instance and assign that configuration to the appropriate projects.
+| ## Configuring multiple DevOps Platform instances
+| SonarQube can report your Quality Gate status to multiple DevOps Platform instances. To do this, you need to create a configuration for each DevOps Platform instance and assign that configuration to the appropriate projects.
|
-| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM.
+| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each DevOps Platform.
|
-| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
+| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each DevOps Platform. If you have multiple configurations of the same DevOps Platform connected to SonarQube, you have to create projects manually.
[[collapse]]
| ## Linking issues
Setting up the import of BitBucket Server repositories into SonarQube allows you to easily create SonarQube projects from your Bitbucket Server repositories. If you're using [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) or above, this is also the first step in adding pull request decoration.
[[info]]
-| To import your Bitbucket repositories into SonarQube, you can only have one global configuration of Bitbucket, including Bitbucket Server and Bitbucket Cloud. See the **Configuring multiple ALM instances** section below for more information.
+| To import your Bitbucket repositories into SonarQube, you can only have one global configuration of Bitbucket, including Bitbucket Server and Bitbucket Cloud. See the **Configuring multiple DevOps Platform instances** section below for more information.
To set up the import of BitBucket Server repositories:
-1. Set your global ALM integration settings
+1. Set your global DevOps Platform integration settings
1. Add a personal access token for importing repositories
-### Setting your global ALM Integration settings
-To set your global ALM Integration settings, navigate to **Administration > ALM Integrations**, select the **Bitbucket** tab, and select **Bitbucket Server** as the variant you want to configure. From here, specify the following settings:
+### Setting your global DevOps Platform Integration settings
+To set your global DevOps Platform Integration settings, navigate to **Administration > DevOps Platform Integrations**, select the **Bitbucket** tab, and select **Bitbucket Server** as the variant you want to configure. From here, specify the following settings:
- **Configuration Name** (Enterprise and Data Center Edition only) – The name used to identify your Bitbucket Server configuration at the project level. Use something succinct and easily recognizable.
- **Bitbucket Server URL** – your instances URL. For example, `https://bitbucket-server.your-company.com`.
### Reporting your Quality Gate status in manually created or existing projects
SonarQube can also report your Quality Gate status to Bitbucket Server for existing projects and manually-created projects. After you've updated your global settings as shown in the **Importing your Bitbucket Server repositories into SonarQube** section above, set the following project settings at **Project Settings > General Settings > DevOps Platform Integration**:
-- **Configuration name** – The configuration name that corresponds to your ALM instance.
+- **Configuration name** – The configuration name that corresponds to your DevOps Platform instance.
- **Project Key** – the project key is part of your BitBucket Server repository URL (.../projects/**{KEY}**/repos/{SLUG}/browse).
- **Repository SLUG** – The repository slug is part of your BitBucket Server repository URL (.../projects/{KEY}/repos/**{SLUG}**/browse).
| Because of the nature of a mono repository, SonarQube scanners might read all project names of your mono repository as identical. To avoid having multiple projects with the same name, you need to pass the `sonar.projectName` parameter to the scanner. For example, if you're using the Maven scanner, you would pass `mvn sonar:sonar -Dsonar.projectName=YourProjectName`.
[[collapse]]
-| ## Configuring multiple ALM instances
-| SonarQube can report your Quality Gate status to multiple ALM instances. To do this, you need to create a configuration for each ALM instance and assign that configuration to the appropriate projects.
+| ## Configuring multiple DevOps Platform instances
+| SonarQube can report your Quality Gate status to multiple DevOps Platform instances. To do this, you need to create a configuration for each DevOps Platform instance and assign that configuration to the appropriate projects.
|
-| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM.
+| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each DevOps Platform.
|
-| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
+| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each DevOps Platform. If you have multiple configurations of the same DevOps Platform connected to SonarQube, you have to create projects manually.
[[collapse]]
| ## Linking issues
### Step 3: Updating your SonarQube global settings with your GitHub App information
After you've created and installed your GitHub App, update your global SonarQube settings to finish integration and allow for the import of GitHub projects.
-Navigate to **Administration > Configuration > General Settings > ALM Integrations > GitHub** and specify the following settings:
+Navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations > GitHub** and specify the following settings:
- **Configuration Name** (Enterprise and Data Center Edition only) – The name used to identify your GitHub configuration at the project level. Use something succinct and easily recognizable.
- **GitHub URL** – For example, `https://github.company.com/api/v3` for GitHub Enterprise or `https://api.github.com/` for GitHub.com.
If you're creating your projects manually or adding Quality Gate reporting to an existing project, see the following section.
### Reporting your Quality Gate status in manually created or existing projects
-SonarQube can also report your Quality Gate status to GitHub pull requests and branches for existing and manually-created projects. After you've created and installed your GitHub App and updated your global ALM Integration settings as shown in the **Importing your GitHub repositories into SonarQube** section above, set the following project settings at **Project Settings > General Settings > DevOps Platform Integration**:
+SonarQube can also report your Quality Gate status to GitHub pull requests and branches for existing and manually-created projects. After you've created and installed your GitHub App and updated your global DevOps Platform Integration settings as shown in the **Importing your GitHub repositories into SonarQube** section above, set the following project settings at **Project Settings > General Settings > DevOps Platform Integration**:
- **Configuration name** – The configuration name that corresponds to your GitHub instance.
- **Repository identifier** – The path of your repository URL.
| By default, **Enable analysis summary under the GitHub Conversation tab** is on and your pull request analysis will be shown under both the **Conversation** and **Checks** tabs in GitHub. When off, your pull request analysis summary is only shown under the **Checks** tab.
[[collapse]]
-| ## Configuring multiple ALM instances
-| SonarQube can report your Quality Gate status to multiple ALM instances. To do this, you need to create a configuration for each ALM instance and assign that configuration to the appropriate projects.
+| ## Configuring multiple DevOps Platform instances
+| SonarQube can report your Quality Gate status to multiple DevOps Platform instances. To do this, you need to create a configuration for each DevOps Platform instance and assign that configuration to the appropriate projects.
|
-| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM.
+| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each DevOps Platform.
|
-| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
+| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each DevOps Platform. If you have multiple configurations of the same DevOps Platform connected to SonarQube, you have to create projects manually.
[[collapse]]
| ## Linking issues
To update your global SonarQube settings:
-Navigate to **Administration > Configuration > General Settings > ALM Integrations > GitHub > GitHub Authentication** and update the following:
+Navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations > GitHub > GitHub Authentication** and update the following:
1. **Enabled** – set the switch to `true`.
1. **Client ID** – the Client ID is found below the GitHub App ID on your GitHub App's page.
After creating your app, update your global SonarQube settings:
-Navigate to **Administration > Configuration > General Settings > ALM Integrations > GitHub > GitHub Authentication** and update the following:
+Navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations > GitHub > GitHub Authentication** and update the following:
1. **Enabled** – set the switch to `true`.
1. **Client ID** – the Client ID is found below the GitHub App ID on your GitHub App's page.
- **Redirect URI** – enter your SonarQube URL with the path `/oauth2/callback/gitlab`. For example, `https://sonarqube.mycompany.com/oauth2/callback/gitlab`.
- **Scopes** – select **api** if you plan to enable group synchronization. Select **read_user** if you only plan to delegate authentication.
-After saving your application, GitLab takes you to the app's page. Here you find your **Application ID** and **Secret**. Keep these handy, open your SonarQube instance, and navigate to **Administration > Configuration > General Settings > ALM Integrations > GitLab > Authentication**. Set the following settings to finish setting up GitLab authentication:
+After saving your application, GitLab takes you to the app's page. Here you find your **Application ID** and **Secret**. Keep these handy, open your SonarQube instance, and navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations > GitLab > Authentication**. Set the following settings to finish setting up GitLab authentication:
- **Enabled** – set to `true`.
- **Application ID** – the Application ID is found on your GitLab app's page.
On the login form, the new "Log in with GitLab" button allows users to connect with their GitLab accounts.
### GitLab group synchronization
-Enable **Synchronize user groups** at **Administration > Configuration > General Settings > ALM Integrations > GitLab** to associate GitLab groups with existing SonarQube groups of the same name. GitLab users inherit membership to subgroups from parent groups.
+Enable **Synchronize user groups** at **Administration > Configuration > General Settings > DevOps Platform Integrations > GitLab** to associate GitLab groups with existing SonarQube groups of the same name. GitLab users inherit membership to subgroups from parent groups.
To synchronize a GitLab group or subgroup with a SonarQube group, name the SonarQube group with the full path of the GitLab group or subgroup URL.
1. Add a personal access token for importing repositories
### Setting your global settings
-To import your GitLab projects into SonarQube, you need to first set your global SonarQube settings. Navigate to **Administration > Configuration > General Settings > ALM Integrations**, select the **GitLab** tab, and specify the following settings:
+To import your GitLab projects into SonarQube, you need to first set your global SonarQube settings. Navigate to **Administration > Configuration > General Settings > DevOps Platform Integrations**, select the **GitLab** tab, and specify the following settings:
- **Configuration Name** (Enterprise and Data Center Edition only) – The name used to identify your GitLab configuration at the project level. Use something succinct and easily recognizable.
- **GitLab URL** – The GitLab API URL.
| Because of the nature of a mono repository, SonarQube scanners might read all project names of your mono repository as identical. To avoid having multiple projects with the same name, you need to pass the `sonar.projectName` parameter to the scanner. For example, if you're using the Maven scanner, you would pass `mvn sonar:sonar -Dsonar.projectName=YourProjectName`.
[[collapse]]
-| ## Configuring multiple ALM instances
-| SonarQube can report your Quality Gate status to multiple ALM instances. To do this, you need to create a configuration for each ALM instance and assign that configuration to the appropriate projects.
+| ## Configuring multiple DevOps Platform instances
+| SonarQube can report your Quality Gate status to multiple DevOps Platform instances. To do this, you need to create a configuration for each DevOps Platform instance and assign that configuration to the appropriate projects.
|
-| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM.
+| - As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each DevOps Platform.
|
-| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
+| - Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each DevOps Platform. If you have multiple configurations of the same DevOps Platform connected to SonarQube, you have to create projects manually.
[[collapse]]
| ## Linking issues
To run project analysis with Jenkins, you need to install and configure the following Jenkins plugins _in Jenkins_:
- The SonarQube Scanner plugin.
-- The Branch Source plugin that corresponds to your ALM (Bitbucket Server, GitHub, or GitLab) if you're analyzing multibranch pipeline jobs in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) or above.
+- The Branch Source plugin that corresponds to your DevOps Platform (Bitbucket Server, GitHub, or GitLab) if you're analyzing multibranch pipeline jobs in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) or above.
See the **Installing and Configuring your Jenkins plugins** section below for more information.
### Branch Source plugin
_Required to analyze multibranch pipeline jobs in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) or above_
-Click your ALM below to expand the instructions on installing and configuring the Branch Source plugin.
+Click your DevOps Platform below to expand the instructions on installing and configuring the Branch Source plugin.
[[collapse]]
| ## BitBucket Server
You can easily configure and analyze your projects with Jenkins through the tutorial in SonarQube.
[[info]]
-| You need to set up SonarQube to import your repositories before accessing the tutorial. See the **ALM Integrations** in the left-side navigation of this documentation for more information.
+| You need to set up SonarQube to import your repositories before accessing the tutorial. See the **DevOps Platform Integrations** in the left-side navigation of this documentation for more information.
|
-| A tutorial is currently available for all supported ALMs except Azure DevOps.
+| A tutorial is currently available for all supported DevOps Platforms except Azure DevOps.
To access the tutorial:
* anything else (CLI) - [SonarScanner](/analysis/scan/sonarscanner/)
[[info]]
-| SonarQube integrations are supported for popular ALMs: GitHub Enterprise and GitHub.com, BitBucket Server, Azure Devops Server and Azure DevOps Services.
+| SonarQube integrations are supported for popular DevOps Platforms: GitHub Enterprise and GitHub.com, BitBucket Server, Azure Devops Server and Azure DevOps Services.
[[warning]]
| We do not recommend running an antivirus scanner on the machine where a SonarQube analysis runs, it could result in unpredictable behavior.
For example if you're using SonarQube Community Edition, which includes analysis of Java and JavaScript, but not C++, all `.java` and `.js` files would be loaded, but `.cpp` files would be ignored.
## What about branches and pull requests?
-_Developer Edition_ adds the ability to analyze your project's [branches](/branches/overview/) and [pull requests](/analysis/pull-request/) as well as the ability to automatically decorate pull requests in some ALM interfaces.
+_Developer Edition_ adds the ability to analyze your project's [branches](/branches/overview/) and [pull requests](/analysis/pull-request/) as well as the ability to automatically report your pull request analysis to your DevOps Platform interface.
## What happens during analysis?
During analysis, data is requested from the server, the files provided to the analysis are analyzed, and the resulting data is sent back to the server at the end in the form of a report, which is then analyzed asynchronously server-side.
Before analyzing your Pull Requests, make sure the Pull Request branch is checked out. Avoid any attempt at previewing the merge or actions involving your main branch.
-## Pull request decoration
-You can also add pull request decoration that shows the Pull Request analysis and Quality Gate directly in your ALM's interface. To set up pull request decoration, see the ALM integration page that corresponds with your ALM:
+## Report pull request status to your DevOps Platform
+You can also report the pull request analysis and Quality Gate status directly in your DevOps Platform's interface. To set up pull request decoration, see the DevOps Platform integration page that corresponds with your DevOps Platform:
- [GitHub Enterprise and GitHub.com](/analysis/github-integration/)
- [GitLab Self-Managed and GitLab.com](/analysis/gitlab-integration/)
- [Bitbucket Server](/analysis/bitbucket-integration/)
| Parameter Name | Description |
| --------------------- | ---------------------------------- |
-| `sonar.pullrequest.key` | Unique identifier of your Pull Request. Must correspond to the key of the Pull Request in your ALM.<br/> e.g.: `sonar.pullrequest.key=5` |
+| `sonar.pullrequest.key` | Unique identifier of your Pull Request. Must correspond to the key of the Pull Request in your DevOps Platform.<br/> e.g.: `sonar.pullrequest.key=5` |
| `sonar.pullrequest.branch` | The name of the branch that contains the changes to be merged.<br/> e.g.: `sonar.pullrequest.branch=feature/my-new-feature` |
| `sonar.pullrequest.base` | The branch into which the Pull Request will be merged. <br/> Default: master <br/> e.g.: `sonar.pullrequest.base=master` |
\ No newline at end of file
* Azure DevOps Services
## Analysis
-For information on setting up analysis with the SonarScanner for Azure DevOps, see the [Azure DevOps ALM integration](/analysis/azuredevops-integration/) page.
+For information on setting up analysis with the SonarScanner for Azure DevOps, see the [Azure DevOps DevOps Platform integration](/analysis/azuredevops-integration/) page.
4. One or more SonarScanners running on your Build / Continuous Integration Servers to analyze projects
## Integration
-The following schema shows how SonarQube integrates with other ALM tools and where the various components of SonarQube are used.
+The following schema shows how SonarQube integrates with other DevOps Platform tools and where the various components of SonarQube are used.
1. Developers code in their IDEs and use [SonarLint](https://sonarlint.org) to run local analysis.
This is the default branch and typically corresponds to what's being developed for your next release. This branch is usually known within a development team as "master" or "head" and is analyzed when no specific branch parameters are provided. SonarQube labels this branch as **Main Branch**, and, with Community Edition, this is the only branch you can analyze.
-Adding projects by ALM copies the main branch name in SonarQube from the main branch name in your repository. See **ALM Integrations** in the documentation navigation for more information on adding your project from an ALM.
+Adding projects by DevOps Platform copies the main branch name in SonarQube from the main branch name in your repository. See **DevOps Platform Integrations** in the documentation navigation for more information on adding your project from an DevOps Platform.
If you add your project manually, your main branch defaults to the name "master".
## Keeping your "master" branch history when upgrading from Community Edition to a commercial edition
[[info]]
-| If you added a SonarQube project from an ALM instead of manually, the name of the main branch in SonarQube is copied from the name of the main branch in your repository, and you shouldn't have any branch history issues when upgrading to a commercial edition.
+| If you added a SonarQube project from an DevOps Platform instead of manually, the name of the main branch in SonarQube is copied from the name of the main branch in your repository, and you shouldn't have any branch history issues when upgrading to a commercial edition.
In Community Edition, if you create a project manually, your analyzed branch is named "master" by default.
In a typical development process:
-1. Developers develop and merge code in an IDE (preferably using [SonarLint](https://www.sonarlint.org/) to receive immediate feedback in the editor) and check-in their code to their ALM.
+1. Developers develop and merge code in an IDE (preferably using [SonarLint](https://www.sonarlint.org/) to receive immediate feedback in the editor) and check-in their code to their DevOps Platform.
1. An organization’s continuous integration (CI) tool checks out, builds, and runs unit tests, and an integrated SonarQube scanner analyzes the results.
1. The scanner posts the results to the SonarQube server which provides feedback to developers through the SonarQube interface, email, in-IDE notifications (through SonarLint), and decoration on pull or merge requests (when using [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and above).
### Analyzing pull requests
-Starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can integrate SonarQube to be part of your pull or merge request process. Issuing a pull request can trigger a branch analysis and add pull request decoration to see your branch analysis directly in your ALM's interface in addition to the SonarQube interface. For more information, see the [Pull Request Analysis Overview](/analysis/pull-request/).
+Starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can integrate SonarQube to be part of your pull or merge request process. Issuing a pull request can trigger a branch analysis and add pull request decoration to see your branch analysis directly in your DevOps Platforms's interface in addition to the SonarQube interface. For more information, see the [Pull Request Analysis Overview](/analysis/pull-request/).
## Writing Clean and Safe Code
Using Http header authentication is an easy way integrate your SonarQube deployment with an in-house SSO implementation.
## GitHub and GitLab Authentication
-You can delegate authentication to GitHub Enterprise and GitHub.com or GitLab Self-Managed and GitLab.com. See the corresponding ALM integration page for more information:
+You can delegate authentication to GitHub Enterprise and GitHub.com or GitLab Self-Managed and GitLab.com. See the corresponding DevOps Platform integration page for more information:
- [GitHub Enterprise and GitHub.com](/analysis/github-integration/)
- [GitLab Self-Managed and GitLab.com](/analysis/gitlab-integration/)
## Pull Request Analysis
-You can use Pull Request analysis and decoration to make sure your code is meeting your standards before you merge. Pull Request analysis lets you see your Pull Request's Quality Gate in the SonarQube UI. You can then decorate your Pull Requests with SonarQube issues directly in your ALM's interface.
+You can use Pull Request analysis and decoration to make sure your code is meeting your standards before you merge. Pull Request analysis lets you see your Pull Request's Quality Gate in the SonarQube UI. You can then decorate your Pull Requests with SonarQube issues directly in your DevOps Platform's interface.
For more information on setting up Pull Request analysis and decoration, see the [Pull Request](/analysis/pull-request/) documentation.
]
},
{
- "title": "ALM Integration",
+ "title": "DevOps Platform Integration",
"children": [
"/analysis/github-integration/",
"/analysis/gitlab-integration/",
]
},
{
- "title": "ALM Integration",
+ "title": "DevOps Platform Integration",
"children": [
"/analysis/github-integration/",
"/analysis/gitlab-integration/",
projects / sonarqube.git / commitdiff