From Code to Cloud: CI/CD Workflows for Bicep That Scale

Infrastructure as Code is powerful—but without proper pipelines, you’re flying blind. In this session, we’ll explore how to build robust CI/CD workflows for Bicep using GitHub Actions. You’ll learn how to add value at every step of the pipeline: syntax validation, testing with Pester, policy checks with PSRule for Azure, security scanning with open-source tools, cost estimation, and safe deployments using what-if. We will also check a hot off the press feature: Bicep Snapshots.

We’ll also cover how to structure environments, introduce manual approvals, and keep your workflows clean and maintainable. Expect a mix of best practices, practical guidance, and a live demo that ties it all together. Whether you’re just getting started with Bicep or looking to level up your DevOps game, this talk will equip you with actionable insights to ship your infrastructure safer and smarter.

Transcript

1. From Code to Cloud: CI/CD Workflows for Bicep That Scale David Pazdera
2. About me ❖ solution architect @ Cegal ❖ 20+ years of xp ❖ meetups, conferences, ACP, communities (ALZ, Azure Arc, Bicep, AVM) ❖ GH | LiN | Sessionize | SpeakerDeck | X : pazdedav handle ❖ Blog: azurescholar.cloud
3. THE BIG PICTURE
4. Tools and services map
5. BRIEF GITHUB ACTIONS REFRESHER
6. Anatomy of GitHub Actions workflow
7. GitHub Hosted Runners Standard runners for public repos ❖ ubuntu-latest: 4 vCPU, 16 GB RAM, 14 GB SSD, x64 ❖ arm64 runners in Public Preview Large runners ❖ More RAM, CPU, and disk space ❖ Static IP addresses ❖ Azure private networking ❖ The ability to group runners ❖ Autoscaling to support concurrent workflows ❖ GPU-powered runners Default images ❖ ubuntu-latest ❖ AzCopy 10.29.1, ❖ Bicep 0.36.1, ❖ Azure CLI 2.74.0, ❖ GitHub CLI 2.74.0, ❖ PowerShell 7.4.10 ❖ Az: 12.1.0, ❖ Microsoft.Graph: 2.28.0, ❖ Pester: 5.7.1, ❖ PSScriptAnalyzer: 1.24.0 https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md
8. GitHub Hosted Runners Standard runners for public repos ❖ ubuntu-latest: 4 vCPU, 16 GB RAM, 14 GB SSD, x64 ❖ arm64 runners in Public Preview Large runners ❖ More RAM, CPU, and disk space ❖ Static IP addresses ❖ Azure private networking ❖ The ability to group runners ❖ Autoscaling to support concurrent workflows ❖ GPU-powered runners Default images ❖ ubuntu-latest ❖ AzCopy 10.29.1, ❖ Bicep 0.36.1, ❖ Azure CLI 2.74.0, ❖ GitHub CLI 2.74.0, ❖ PowerShell 7.4.10 ❖ Az: 12.1.0, ❖ Microsoft.Graph: 2.28.0, ❖ Pester: 5.7.1, ❖ PSScriptAnalyzer: 1.24.0 https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md
9. DESIGN YOUR WORKFLOW
10. Workflow design process ❖ main steps in your innerLoop flow ❖fast feedback before pushing to remote feature branch ❖run tools locally (CLI, VS Code Tasks) ❖ checks (validations) for transparency in GH Actions ❖ one or more workflows
11. How many workflows How many workflows? • By lifecycle: Validate, Preview, Deploy • By environment: Dev, Test, Prod workflows Pros: • Easier to maintain and debug • More control and reuse • Faster iteration cycles Cons: • More configuration overhead • Cross-workflow dependencies
12. How many jobs ❖ Parallel execution → Faster pipelines ❖ Error isolation → Easier troubleshooting ❖ Dependency management → use needs: to order execution ❖ Conditions → use if: to skip some jobs or steps ❖ Triggers (scenarios) I want to “model” ❖ Speed vs. repeating the same steps in several jobs (checkout, login, etc.)
13. Common types of jobs Job Type Purpose lint-bicep Run ‘bicep build’ for syntax errors validate Run ‘az deployment validate’ security-scan Use Checkov, PSRule, or AzSK deploy Deploy with Azure CLI notify Send update to Slack/Teams
14. CI – push to feature branch lint validate security scan psrule what-if snapshot
15. CD – pull request to main lint deploy test what-if prod approve prod deploy prod
16. CODE REUSE AND FLEXIBILITY
17. Code reuse and flexibility ❖ reusable workflows ❖ composite actions ❖ parametrize ❖ inputs for actions ❖ inputs for workflow-dispatch trigger ❖ ENV VARS in workflow ❖ needs – if - ${{ env.xxx }} when declaring values for params (optional steps as input params) ❖ matrix
18. BRINGING SEC INTO THE MIX
19. Secure your code and environments ❖ Separation of environments ❖ environment secrets and vars ❖ separate workload identities (OIDC federated creds.) ❖ Rulesets (branch protection) ❖ Validation = manual approval (for environments) ❖ Shift Left = security scanning done early (in CI stage) ❖ Refer to “marketplace” actions using their SHA, not tags… because…
20. ❖ tj-actions/changed-files ❖ ~23K repos using it ❖ retagged existing release version ❖ dumped runner’s memory – search for env vars & secrets – double-base64-encode – print to workflow logs
21. Example
22. DEVELOPER PRODUCTIVITY
23. Coding environment Local dev environment Remote dev environment All tools installed locally + All tools in a Dev Container GitHub Codespaces Microsoft DevBox
24. Coding ‘landing zone’
25. Boost developer productivity …without sacrificing security ❖ repo template with structure and CI/CD workflow ‘stabs’ pointing to reusable workflows ❖ configure reusable workflows in the org ❖ compliance with code-first infrastructure lifecycle ❖ humans are only Readers in Prod (SRE can PIM elevate for emergency and reconcile code/state afterwards) ❖ humans have Write access to Test
26. DEMO TIME…
27. Wrap-up and Q&A USE GITHUB ENVIRONMENTS FOR GATED DEPLOYMENTS KEEP PIPELINES MODULAR AND DRY USE OIDC WITH AZURE FOR SECURE DEPLOYMENTS SEPARATE INFRA MODULES AND PIPELINES DOCUMENT PIPELINE BEHAVIOR IN REPO