Marcus Felling

Hey, you. You’re not manually deploying your Azure Bicep Infrastructure as Code, are you?!? Let’s prevent that next production outage, help your team collaborate on changes, and enable more frequent deployments. In this post, I’ll outline what tooling is available to integrate Bicep in your pipelines, and some good practices for building and deploying.

I wanted to document this after spending a frustrating amount of time troubleshooting getting this setup. I was getting this error when running Terraform Plan:

Error building AzureRM Client: obtain subscription() from Azure CLI: Error parsing json result from the Azure CLI: Error waiting for the Azure CLI: exit status 1: ERROR: Please run 'az login' to setup account.

Why would you choose Microsoft’s new Bicep DSL over HashiCorp’s Terraform? I would like to give you my perspective, as someone who ditched ARM templates for Terraform in most of my Infrastructure as Code projects. To set the context of this blog post, I’ll be talking about Azure focused customers. Also, I won’t be going over the basics of what Bicep is (that can be found in README here) or comparing it to other IaC solutions like Pulumi or Farmer. If there is interest, I can cover those in another blog post. This will be a direct comparison to Terraform.
Note: Opinions expressed are solely my own and do not express the views or opinions of my employer.

There are two main ways to create re-usable components for Azure Pipelines. I’ll review the pros and cons of each and talk about when it makes sense to use one over the other. Keep in mind that the two are not mutually exclusive, so it may make sense to use a combination of both.

I’ve worked with quite a few teams who aren’t aware of, or forget about, the Definition of “Done”. In my opinion, this is one of the easiest, low effort, high impact elements of Agile that a team can adopt.

I’ve been a long time user of Azure Pipelines. It’s a very mature and powerful platform, that integrates really well with other parts of the Azure DevOps suite, to provide end-to-end traceability of the software development lifecycle. However, Microsoft is investing heavily in GitHub which now has some very appealing capabilities: source code security, development insights and analytics, open source and innersource management, etc. As these new capabilities get built out in GitHub, I’d like to explore what is takes to move things over. In this post I’ll be documenting what it takes to port one of my existing Azure Pipelines (YAML) to GitHub Actions.

The size of your TFS/Azure DevOps Server collection databases will grow over time, and it’s not a trivial task figuring out how to cleanup. This conversation usually begins in preparation for an upgrade or migration to Azure DevOps Services. I have some general steps you can take to begin these efforts.

I’ve seen it too many times. It all starts when somebody is given access to a new “production” Azure subscription that’s pay-as-you-go. A new resource is created for the first time on a Friday, running up costs over the weekend, resulting in a surprisingly large bill. The cloud is too expensive!

I often get asked, “why can’t I update any of the fields on the Associated Automation tab of a Test Case?”