Getting Started with Azure DevOps
If your code is on Azure, go to the SonarCloud 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 SonarCloud 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 SonarCloud account, creating a SonarCloud 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.
Once you have successfully logged in, you will see the SonarCloud welcome screen.
Select Import an organization from Azure to bring your projects into SonarCloud.
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 SonarCloud setup page.
We strongly encourage you to add a technical user to your organization, log in to SonarCloud using that technical user, and use the access token of that technical user to connect your Azure DevOps organization to SonarCloud. 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.
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 (PATs) contain the security credentials for Azure DevOps and identify your SonarCloud instance as an accessible organization to define its scope of access.
During a normal analysis using the SonarCloud extension for Azure DevOps, Azure sends information to Sonar and the results are displayed in SonarCloud. 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.
When you set up your connection to Azure DevOps as described here, your Azure DevOps organization is bound to SonarCloud, and the PAT from the Azure organization is registered at the SonarCloud organization level (not at the SonarCloud 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 SonarCloud 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 SonarCloud 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.
- 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 SonarCloud using that technical user, and use the access token of that technical user to connect your Azure DevOps organization to SonarCloud. See the Azure documentation for more information about access levels.
SonarCloud is set up to mirror the way that code is organized in Azure DevOps (and other repository providers):
- Each SonarCloud 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 SonarCloud organization corresponds one-to-one with an Azure DevOps organization.
In this step, you will create a SonarCloud organization that corresponds to your Azure DevOps organization.
SonarCloud will suggest a key for your SonarCloud organization. This is a name unique across all organizations within SonarCloud. You can accept the suggestion or change it manually. The interface will prevent you from changing it to an already existing key.
SonarCloud 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.
Next, you will be asked to choose a SonarCloud subscription plan. If all the repositories to be analyzed are public on Azure DevOps, 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 one or more private repositories, you must select a paid plan. All paid 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.
A plan is always associated one-to-one with a SonarCloud 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 SonarCloud organization will be created!
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 SonarCloud organization. A corresponding SonarCloud project will be created for each git repository.
SonarCloud 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.
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 New code definition page.
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 SonarCloud.
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 SonarCloud 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.
SonarCloud 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. SonarCloud 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.
SonarCloud’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 SonarCloud 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 SonarCloud, please see the Azure DevOps Labs tutorial, written in part by SonarSource authors and recently updated (in late 2023).
If you log into SonarCloud using an email address that you previously used to log into another DevOps platform, you need to be aware that SonarCloud 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 SonarCloud organization). If you then decide to switch back to GitHub, the Azure DevOps email notifications will be discontinued.