Intro Azure Template Specs is an option for storing Azure ARM templates inside Azure to ease sharing templates across your organization. Accessing Template Specs is controlled with RBAC assignments, making Template Specs security like most other Azure resources. Template Specs deploys resources in Azure and is compatible with the tools we know already, so PowerShell, Azure CLI, Pipelines, and the Azure Portal. To deploy from a Template Spec, a user only needs “Reader” permissions to the Template Spec, but permissions to create the resource in Azure are also required.

Intro In this post, I want to show you how to deploy a .Net 6.0 website to Azure using Azure DevOps. I will create a demo website in Visual Studio using the Microsoft provided templates and publish the website to Azure using a pipeline. Workflow The flow for the demo website is simple. I update text on the website and commit the code to an Azure DevOps repository. From Azure DevOps, I can use the repository in a pipeline to deploy the code to Azure.

Intro I want to create the Azure resources needed to build Azure Functions in this post. I will guide you through the necessary bicep files to deploy a Storage Account, Application Insights, App Service Plan, and the Azure Function. You will deploy everything with code by the end of this post, including a demo function. All code can be found on GitHub . Workflow As shown below, the workflow is:

Intro I have previously written a post on how to use Azure Key Vault with GitHub Actions, and this time I want to show you have to use Key Vault with Bicep deployments in Azure. The reason behind using Key Vault is to avoid having any passwords or secrets stored in templates. Using Key Vault, I can reference a secret that the deployment will look up at deployment time and not display in any log files.

Intro In this blog post, I want to show you how to maintain route tables and network security group (NSG) configurations in Azure using Azure DevOps and pipelines. I have already written a post on the NSG part, but I have updated a few things since then, so I want to show that in this post. You can find all the files in this post in their full length on my GitHub .

Intro In this post, I want to show you how you can easily set up Azure DevOps to control your Azure Function Apps (AF). Out of the box, AF supports editing in the portal or using VS Code / Visual Studio for both editing and updating. While both methods are fine, I prefer to use Azure DevOps for AF instead, enabling source control. Want to know how I do this? Read on, and I will show you.

As you may know, I am a bit fan of automation and source control, and the reason for this is that these tools help me provide a stable IT environment for customers and internal use. The confidence that doing an installation or update and that the deployment is executed exactly as I did the last time is something I appreciate. Using automation doesn’t mean there are no mistakes, but I only have to fix it one time instead of remembering or doing a document each time explaining the change.

We all know that we shouldn’t put any passwords into our code and check them into source control, but many guides (including my own) often reference a password variable or parameter. The parameter option is actually OK, in my opinion, as long as you then reference a secure password from either an Azure DevOps library, GitHub Secret, or using an Azure key vault. In this post, I want to show you how to reference secrets stored in the Azure key vault and use them in a GitHub action and pass the value to a Bicep deployment.

This is the last part of this blog series, and here I want to show you how to use a JSON configuration file and a PowerShell script to deploy the same environment as you have seen in the first five parts of the series. This deployment type will feel familiar to many consultants since PowerShell is widely used among consultants. This deployment method can ease them into a DevOps mindset. Doing it this way enables flexibility around which part of the code to deploy by using if statements in the PowerShell script.

In this part of the series, I will create two virtual machines and join them in my on-premises domain. These machines will be Citrix Cloud Connectors that will serve my Citrix environment with a new resource location in Azure. The Cloud Connectors will be deployed in an Azure Availability Set to ensure high availability. Source code can be found on my GitHub, find it here . I start with the creation of a new branch for my code, this will be called “VM”.