Where to store Azure Pipelines Variables?

Question Where should variables be stored for deploying infrastructure-as-code in Azure DevOps pipelines to Azure? Resources need to be deployed to different regions and environments, and attributes for these need to be stored somewhere. Options Six options spring to mind. Parameter files. Seems like the obvious choice. Template file defaults in azuredeploy.json or main.bicep Azure DevOps Library variable groups. Seems good, a single place Azure Pipelines variables in individual pipelines Configuration file within the project source code Runtime parameters for setting values at run time Let’s go through each option and then discuss my preferred approach. ...

Fri, 4 March 2022 · 7 min · Mark

Automate Setting the SqlIaaS Backup Container

Even though Microsoft offer Azure Sql Database and Azure Sql Managed Instance, there are occasions when SQL Server in a VM is required. The SqlIaaS Azure Resource If you’ve read my posts before you will know that I deploy resources to the cloud using infrastructure-as-code, with my preferred language being bicep. As a lazy developer, I like to use built-in offerings and PaaS wherever possible. For SQL server on VMs in Azure, the resource Microsoft.SqlVirtualMachine/sqlVirtualMachines is great. ...

Fri, 25 February 2022 · 2 min · Mark

Deployments with Bicep and Azure DevOps

Goodbye JSON Since Microsoft released bicep version 0.3 I thought I’d give it a try because anyone that’s authored ARM templates will know, they tend to make your eyes bleed after a while. Bicep aims to drastically simplify the authoring experience with a cleaner syntax, improved type safety, and better support for modularity and code re-use. I’m sold! I reverse-engineered an existing simple template that deploys two storage accounts by using bicep decompile and got a template like this: ...

Sun, 11 April 2021 · 5 min · Mark

CI With Jenkins, Sql Server and Windows Containers

Why use Windows Containers? When creating database applications we need consistency in all our environments to ensure quality releases. Traditionally developers might have their own instance of SQL Server on their workstation to develop against. Database projects would be created in SSDT and pushed to source control when ready for testing. If you’re not using SSDT for database development already, then you should seriously consider it to make your life easier and increase the quality of your releases. Ed Elliot explains why in this blog post. ...

Sun, 27 August 2017 · 8 min · Mark