Of many things that make PowerShell stand apart in the world of scripting languages, perhaps two are most fundamental to it: first, its treats everything as Objects and second, the ability to pipe objects from one cmdlet to another. Using this capability, we can effortlessly link multiple cmdlets together. Doing this will also throttle the amount of memory that is being allocated (in most cases) that the current session is using for the commands. So, its very natural that you would want to implement pipeline support for your own function, that you just wrote.
Continue reading “Implement Pipeline Support by making proper use of begin, process and end blocks in PowerShell functions”
PowerShell has become de-facto tool of choice for automation in Microsoft world from long time and slowly it is winning over hearts of the Linux administrators as well. Just like with other programming languages, there are many ways to do the same thing in PowerShell. However they differ in little subtle ways. You may or may not notice them in your day to day usage, but if you learn those subtleties, you can quickly improve the performance and results of your automation. This blog post is about one of the such cases only.
Continue reading “Write Advanced functions in PowerShell using various Write Cmdlets”
It is easy to create variables in the Azure Pipelines and they make the pipelines more generic in nature. Therefore, we can customize the release steps as per the context of the stage used. Same goes for the build definitions. Now sometimes, it may happen that the variables are common across multiple build and release definitions. In such a case, instead of defining them again and again, we can use a variable group. A variable group allows us to store values that we want to make available across multiple build and release pipelines. It also prevent duplication of values, making it easier to update all occurrences as one operation.
Continue reading “Share variables across definitions in Azure Pipelines by using variable groups”
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”
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”