Getting started with Azure DevOps
If your code is on Azure, go to the SonarQube Cloud product page and choose Set up or Login, then select Azure from the list of DevOps cloud platforms.
You will be taken to the Microsoft login page. Sign in using your Microsoft credentials.
Setting up a new SonarQube Cloud account with your Azure DevOps service requires that you be logged into both instances because there is some back-and-forth involved between the two platforms.
With an existing Azure DevOps service, you will start by opening a new SonarQube Cloud account, creating a SonarQube Cloud Organization, and connecting it to Azure with an Azure Personal Access Token. With your PAT in place, importing your repositories and configuring the analysis are the next steps to get things going.
See below for full, step-by-step instructions.
Welcome to SonarQube Cloud
Once you have successfully logged in, you will see the SonarQube Cloud welcome screen.
Select Import an organization from Azure to bring your projects into SonarQube Cloud.
Set up your organization
Connect your Azure DevOps organization with SonarQube Cloud
You will be presented with a screen like this:
You need to enter the name of your Azure DevOps organization and an Azure-generated Personal Access Token created in that organization.
To create the token, go to your Azure DevOps organization User settings > Personal access tokens, then select + New token.
On the next page, under Scopes, make sure that you specify at least the scope Code > Read & write.
Then, click Create to generate the token.
When the personal access token is displayed, copy/paste it into the field on the SonarQube Cloud setup page.
We strongly encourage you to add a technical user to your organization, log in to SonarQube Cloud using that technical user, and use the access token of that technical user to connect your Azure DevOps organization to SonarQube Cloud. The Technical user account should be assigned a Basic access type.
Do not set the technical user’s account with a Stakeholder access type to generate your PAT. It is better to add your technical user to the Contributors security group.
Additionally, in your Azure DevOps organization, you will need to ensure that Azure Active Directory Conditional Access Policy Validation is disabled. An Active Directory administrator should go to Organization Settings > Security > Policies > Enable Azure Active Directory Conditional Access Policy Validation and check that the feature is turned off.
Personal access tokens
Personal access tokens (PATs) contain the security credentials for Azure DevOps and identify your SonarQube Cloud instance as an accessible organization to define its scope of access.
How PATs work
During a normal analysis using the SonarQube Cloud extension for Azure DevOps, Azure sends information to Sonar and the results are displayed in SonarQube Cloud. In a pull request analysis, Azure sends information to Sonar. Next, Sonar analyzes the code and then sends the results back to Azure; here, a PAT is needed so that Azure knows to accept the results of your Sonar analysis.
Managing your PAT in SonarQube Cloud
When you set up your connection to Azure DevOps as described here, your Azure DevOps organization is bound to SonarQube Cloud, and the PAT from the Azure organization is registered at the SonarQube Cloud organization level (not at the SonarQube Cloud project level). If you later need to update the value of this token you can find it under Your Organization > Administration > Organization Settings > Azure DevOps connectivity management.
If earlier, you set up an Azure DevOps project manually (not creating a bound organization) you may have registered the PAT at the SonarQube Cloud project level (not the organization level) by filling in the field under Your Organization > Your Project > Administration > General Settings > Pull Requests > Integration with Azure DevOps Services..
Entering the Azure PAT at the organization level or at the project level in SonarQube Cloud can lead to different behavior. We recommend that you follow the tutorial to create a bound organization and make sure that the PAT is entered only at the organization level, not at the project level. The project-level field should be left blank.
PAT failure points
- Azure PATs require an expiration date. Check the Microsoft documentation for details when creating your PAT.
- Azure requires that a user log in every 30 days, or it automatically kills a PAT; this action may cause your related pipeline to fail. Here is an Azure Q&A on this topic.
- Users having the Stakeholder access type can have problems finding their repos when trying to Analyze projects; the Basic access type should be used instead. We strongly encourage you to add a technical user to your organization, log in to SonarQube Cloud using that technical user, and use the access token of that technical user to connect your Azure DevOps organization to SonarQube Cloud. See the Azure documentation for more information about access levels.
About your SonarQube Cloud organization
SonarQube Cloud is set up to mirror the way that code is organized in Azure DevOps (and other repository providers):
- Each SonarQube Cloud project corresponds one-to-one with an Azure DevOps project, which resides in its own Git repository.
- Azure DevOps projects are grouped into Azure DevOps organizations.
- Each SonarQube Cloud organization corresponds one-to-one with an Azure DevOps organization.
In this step, you will create a SonarQube Cloud organization that corresponds to your Azure DevOps organization.
SonarQube Cloud will suggest a key for your SonarQube Cloud organization. This is a name unique across all organizations within SonarQube Cloud. You can accept the suggestion or change it manually. The interface will prevent you from changing it to an already existing key.
SonarQube Cloud does not support linking an organization to more than one DevOps platform. If you want to link to more than one, you will need to create a separate organization to link to each DevOps service.
Choose a plan
Next, you will be asked to choose a SonarQube Cloud subscription plan. If all the repositories to be analyzed are public on your DevOps platform, you can select the Free plan. When using the Free plan, your code and analysis results will be publicly accessible at sonarcloud.io/explore/projects.
If you want to analyze more than 50k lines of private code, then you need to select the Team or Enterprise plan. Monthly plans offer a 14-day free trial period. Once the 14 days have elapsed, the cost is based on the number of lines of code analyzed. For more information, see Managing your subscription.
A plan is always associated one-to-one with a SonarQube Cloud organization and therefore with a single Azure DevOps organization. If you want to onboard multiple Azure workspaces, you must sign up for a separate plan for each.
Once you have chosen a plan and clicked Create Organization, your SonarQube Cloud organization will be created!
Set up your analysis
Import repositories
The next step is to import the projects (that is, individual git repositories) that you want to analyze (from your Azure DevOps organization) into your newly created SonarQube Cloud organization. A corresponding SonarQube Cloud project will be created for each git repository.
SonarQube Cloud will present a list of the repositories in your Azure DevOps organization. Choose those that you want to import and analyze, then select Set Up to continue.
The selected projects will be imported.
Choose your new code definition
The next step is to set the new code definition (NCD) for your project(s). The NCD is a mandatory step and it defines which part of your code is considered new code. This helps you to focus your attention on the most recent changes to your code and allows you to follow the Clean as You Code methodology.
Note that the new code definition you apply at this stage will apply to all of the projects you have selected for analysis. You can change your new code definition later on a per-project basis.
To do this, go to Your Organization > Your Project > Administration > New Code.
For more information, check out the About new code page.
Configure analysis
With Azure DevOps projects the actual analysis is performed in your build environment (cloud CI, local machine, etc.). This means that you must configure your build process to perform the analysis on each build and communicate the results to SonarQube Cloud.
We refer to this analysis method as CI-based analysis (though it may take place in a cloud CI or a manually configured build environment) to contrast it with automatic analysis which works by SonarQube Cloud directly accessing your repository and performing the analysis itself.
However, automatic analysis is currently available only for GitHub projects and only for a subset of languages. It is currently not available for Azure DevOps projects.
SonarQube Cloud will guide you through a tutorial on how to set up your build environment to perform analysis.
The first step is to select your build environment. SonarQube Cloud will present this page:
If you have no particular preference and are setting up a new project on Azure DevOps, we recommend using Azure DevOps Pipelines as your CI.
SonarQube Cloud’s in-product tutorial assumes that the user has experience setting up pipelines in Azure DevOps and will walk you through most of the process. You can check our documentation on the SonarQube Cloud Extension for Azure DevOps if more information is needed to set up your YAML file.
For step-by-step examples to integrate Azure DevOps with SonarQube Cloud, please see the Azure DevOps Labs tutorial, written in part by SonarSource authors and recently updated (in late 2023).
See your analysis results
Your next steps are to check the results of your first analysis and set your new code definition, an important part of implementing a Clean as You Code strategy.
If you log into SonarQube Cloud using an email address that you previously used to log into another DevOps platform, you need to be aware that SonarQube Cloud will automatically associate your email address with the new DevOps platform.
For example, if you log in through Azure DevOps and previously used GitHub, GitHub issues will no longer be assigned to your email address and you will stop receiving GitHub email notifications (via your SonarQube Cloud organization). If you then decide to switch back to GitHub, the Azure DevOps email notifications will be discontinued.
Was this page helpful?
© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.
