You can easily store your environment related secrets in the Azure Pipelines releases as variables and mark them as secrets which will encrypt and hide them. So anyone having access to the release definition would be not able to view them. Most of the times, it suffices as once set, they become encrypted and can not be viewed in text form.
However, sometimes it may happen that the person who keeps the secret would not be the same person as who is creating the release definition. Think of that as a way of segregating the responsibilities between the two. Also, it may be possible that the person who has provisioned the environment is not comfortable to share the secrets with anyone in plain text. After all, the best way to keep a secret is not to tell anyone about it. This is where the Azure Key Vault fits in very nicely. It can be used to store and transfer the secrets/certificates needed for your environment in a secure way.
Continue reading “Store the app secrets in Azure Key Vault and use during Azure Pipelines”
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”
This happens almost every now and then. You are in middle of working on some code changes, modified few files here and there and may be added new files. Now something else comes up urgently and you are asked to do it now. But you do not want to make a commit in middle of the work. In such a case, if you switch branch, your changes are carried over to the another branch as well. So you need a way to save your work temporarily. Fortunately, Git allows this functionality using what is known as Git Stash.
Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.
Continue reading “Save your changes temporarily in Git using Git Stash”
Using MSBuild tool to get code coverage and configure Azure DevOps pipelines to include code coverage results is an easy task for .NET framework based applications. Azure DevOps (formerly VSTS) contains inbuilt functionality to analyze code coverage files generated and publish results back to VSTS itself. However, it is quite a challenge to get it right and working for .NET Core 2.0 based applications. In this blog post, we’ll cover steps on how to get code coverage results for .NET Core based application using SonarQube and Azure DevOps. Continue reading “Configure Code Coverage for Dotnet Core 2.0 based applications using SonarQube and Azure DevOps”
This happens almost every now and then with the developers who are very new to the Git. I’m writing it down in the hope that if somehow the original post on stackoverflow is not available for one or other reasons, people can still find the solution. Also, even after fixing this for multiple times, I do not remember the exact commands, I still end up googling the solution. Sometimes, it takes a lot of time to find the original post as there are so many reasons for .gitignore file not working in intended ways. So the scenario is like this, that you are very new to Git or have some understanding of Git or you are very excited about an idea, you started coding on it, then you initialize and then commit your files. Continue reading “Fixing error with .gitignore file not ignoring files”
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”
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.”