Create Nuget Packages using CI/CD in Azure Pipelines and push to Azure Artifacts feeds

It has been long since I have written blog post about using Nuget Package feeds in VSTS, which can be found here. I have always wanted to write a follow up blog post about how to use feeds further but I was occupied by other priorities and then it fell off my mind. Since then VSTS has been renamed to Azure DevOps and Package feeds are now known as artifacts feeds. However, other than this, most of the things and functionality has been more or less intact in terms of this feature.

For this who are not aware of the Nuget, it is a technology which works on the principal of the package management and very helpful for code sharing in .NET framework and .NET Core based applications. Continue reading “Create Nuget Packages using CI/CD in Azure Pipelines and push to Azure Artifacts feeds”

Configure CI/CD in Azure Pipelines to deploy docker containers as Azure Web App

Few days back, we learned about how to publish Azure Container Instances where-in we can deploy either a container or group of containers and use the same. Azure Web App for Containers allows you to not only run your containers but it also brings forth the PaaS innovations for the Web App. So it brings best of the both worlds together. It also allows you to not worry about the maintaining an container orchestrator mechanism. You can prefer to package their code and dependencies into containers using various CI/CD systems like Jenkins, Maven, Travis CI or VSTS, alongside setting up continuous deployment web hooks with App Service.

In this blog post we’ll learn more about how to deploy .NETCore application packaged as docker container and using CI/CD in Azure Pipelines (Formerly VSTS). Continue reading “Configure CI/CD in Azure Pipelines to deploy docker containers as Azure Web App”

Fail Azure DevOps pipeline if build fail to pass the SonarQube Quality Gate

Using SonarQube extesions from Marketplace for Azure DevOps provides much of the integration functionality between Azure DevOps and SonarQube. Once the build pipeline completes, you can login in SonarQube server and view the code analysis results. Based on the code analysis results against the Quality threshold set or default Quality Gate threshold, it will be assigned a rating. However, there is no way to stop check-in of code, if it fails to passes the Quality Gate criteria. However, we can use some PowerShell and SonarQube Web APIs to do this part for us. In this blog post, we’ll learn steps to do the same. Continue reading “Fail Azure DevOps pipeline if build fail to pass the SonarQube Quality Gate”

Azure DevOps build pipelines fails with error: To use the property “sonar.branch.name”, the branch plugin is required but not installed.

After upgrading our SonarQube Community version to the newly released version, our build pipelines hosted in the Azure DevOps (formerly VSTS) started failing with below errors:

“02:14:02.317 ERROR: Caused by: Validation of project reactor failed:
o To use the property “sonar.branch.name”, the branch plugin is required but not installed. See the documentation of branch support: https://redirect.sonarsource.com/doc/branches.html”

We were using the same release branches that we were using earlier and there was no changes made to the build configuration. Continue reading “Azure DevOps build pipelines fails with error: To use the property “sonar.branch.name”, the branch plugin is required but not installed.”

Using Path filters in Build definition in Azure DevOps / VSTS

Sometimes it happens that for the organization and maintenance purpose, you would like to keep all code related to one component of a product in one place only. Now that component may be complex component having multiple sub parts like API, UI, Database etc. Again, for the purpose of easy maintenance, you would like it all under one repository, which is not an bad idea. Now, imagine if you have different builds configured for different sub-components which are using this source code as their base and are configured to trigger on some event, say commit. Then for each small and big commit, it will trigger build in each of the configured builds. Ideally, if the change was related to only one sub-component say API, then you would need to trigger only API specific build and not the ones for the UI and/or Database.  Continue reading “Using Path filters in Build definition in Azure DevOps / VSTS”