How Can I Improve My Automation Account’s Source Control Setup?

0
2
Asked By TechWhiz42 On

Hey everyone! I've recently integrated Azure DevOps for Source Control with our Automation Account (AA) and I want to make sure I've set everything up correctly. We're a small team primarily dealing with PowerShell Runbooks for automating tasks in Entra and Exchange. Here's how we've organized things so far: IT pushes changes to a 'test' branch, and before merging to 'main', we require a code review through a Pull Request. Once approved, the Runbook is added to the AA. However, I've encountered a few frustrations: 1. Someone needs to have Contributor access to switch the Runtime Environment from PowerShell 5.1 to 7.4. 2. The Contributor role is necessary for testing and publishing the Runbook. 3. Essentially, every time we update the code, a Contributor must re-publish the Runbook, which feels counterproductive. I'm still figuring out the best approach. One thought is to create a separate Automation Account with lower permissions that auto-publishes from the 'test' branch while the 'main' branch does so on the main AA, but I'm unsure if that would work well for testing. I'm looking for any advice or best practices you can share as I haven't found much online about this!

4 Answers

Answered By TerraformGuru88 On

I managed to streamline everything by deploying everything in a single pipeline via Terraform, which works great for me!

Answered By CodeCrafter99 On

I created my own pipeline that leverages PowerShell and the Azure module to deploy both runbooks and modules directly from the Azure DevOps repo. I recommend using one automation account for development and another for production. The pipeline first deploys to dev and only moves to prod after getting approval. By using a workload account with all necessary permissions, you won’t need users to have higher rights directly.

Answered By DevOpsDynamo On

I focus on keeping everything as code. If needed, consider splitting into two pipelines for better management. Using an OIDC-based service principal from Azure DevOps to Azure is a great way to handle permissions, plus you can create multiple DevOps environments for flexibility!

Answered By AzureNinja77 On

I’m with you on that! It’s definitely a solid approach.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.