GitHub Actions with Azure

“Welcome back. Today we're covering GitHub Actions — CI/CD automation built directly into GitHub. If you're already using GitHub for your code, GitHub Actions means you don't need a separate CI/CD platform. Workflows live in your repository, run automatically on code events, and have a massive ecosystem of pre-built actions for deploying to Azure.”

“GitHub Actions is an automation platform that responds to events in your GitHub repository. Push code, open a pull request, create a tag, or schedule a time — all of these can trigger a workflow. Workflows run on runners — GitHub provides Ubuntu, Windows, and macOS runners for free up to a generous monthly limit. The GitHub Marketplace has thousands of pre-built actions for everything from sending Slack notifications to deploying to any cloud provider.”

“A GitHub Actions workflow is a YAML file in the .github/workflows directory of your repository. The 'on' section defines what triggers the workflow — a push to main, a pull request, or a cron schedule. The 'jobs' section defines the work to do. Jobs run in parallel by default, or you can make them depend on each other. Each job runs on a runner and contains steps — either shell commands or references to marketplace actions.”

“Microsoft provides a collection of official GitHub Actions for Azure deployments. The azure/login action handles authentication — you provide Azure credentials as GitHub Secrets and it sets up the Azure CLI context for subsequent steps. Then you chain in the deployment action for your target service — webapps-deploy for App Service, functions-action for serverless functions, or aks-set-context followed by kubectl commands for Kubernetes. These actions handle the complex deployment logic, so your workflow stays clean and readable.”

“Your workflows need credentials to deploy to Azure. GitHub Secrets store sensitive values encrypted at rest, masked in all logs. The traditional approach uses a Service Principal — you create it in Azure, download the JSON credentials, and store them as a GitHub Secret. The modern, more secure approach uses OpenID Connect — GitHub and Azure establish a trust relationship, and Azure issues short-lived tokens on demand. No long-lived credentials to rotate or accidentally expose. Always use OIDC for new workflows.”

“GitHub Environments bring deployment governance to Actions. Define environments for dev, staging, and production. Set protection rules — require specific reviewers to approve before a production deployment proceeds. Add a wait timer as a mandatory delay. Restrict which branches can deploy to production. Every deployment appears in your repository's Environments tab with full history — commit, who approved, success or failure. This is how you maintain control without slowing down your team.”

“GitHub Actions has powerful features for scaling your CI workflows. Matrix builds let you test against multiple versions simultaneously — run your test suite on Node 18, 20, and 22 in parallel with a single job definition. Reusable workflows let you define a workflow once and call it from multiple repositories — perfect for organizations standardizing their deployment process across teams. Composite actions package sequences of steps into a single, reusable unit.”

“Let me build a complete GitHub Actions workflow from scratch. I'll create the workflow YAML file, set up OIDC authentication so we don't need to manage service principal credentials, add a build-and-test job, and add a deploy job that releases to App Service only on merges to main. We'll trigger it with a push and watch the workflow run in the GitHub Actions UI with live logs.”

“GitHub Actions and Azure are a powerful combination — your entire deployment pipeline lives in the same repository as your code. No separate CI server to maintain, no context switching. Next video we move into the security domain — Azure Defender for Cloud, which gives you security posture management and threat protection across your entire Azure environment. See you there.”