USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksAzure Cloud Book
HomeAzure BookInfrastructure and Delivery
PreviousTerraform on Azure: Providers, Modules, Remote State, Plans, Imports, and DriftNextGitOps, Progressive Delivery, Feature Flags, and Rollback
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

10 sections

Progress0%
1 / 10

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

GitHub Actions and Azure DevOps CI/CD for Azure

Continuous integration proves a change can become a trustworthy artifact. Continuous delivery promotes that immutable artifact through environments with policy and evidence. GitHub Actions and Azure Pipelines can both deploy Azure; choose by organization, repository, governance, marketplace, and operating model—not by YAML syntax alone.

Method note: This chapter compares pipeline operating models, authentication, evidence, and release gates rather than pretending YAML fragments are interchangeable. Concrete GitHub Actions and Azure Pipelines setup remains visible in sequence so their different identity and governance prerequisites are clear.

What is a safe pipeline shape?

Rendering diagram...

Build once. Promote the same image/package digest. A production rebuild creates an untested artifact.

How should a pipeline authenticate to Azure?

Use OpenID Connect workload identity federation. The CI platform issues a short-lived identity token; Entra trusts a specific repository/branch/environment or Azure DevOps service connection. No client secret is stored.

Grant separate identities per environment. The pull-request identity can validate and plan, while the protected production environment identity can deploy only after approval. Scope roles to the required subscription/resource group/resources.

What does a GitHub Actions Azure login look like?

yaml
permissions: id-token: write contents: read steps: - uses: actions/checkout@v4 - name: Sign in to Azure with workload identity uses: azure/login@v2 with: client-id: ${{ vars.AZURE_CLIENT_ID }} tenant-id: ${{ vars.AZURE_TENANT_ID }} subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }} - name: Preview Bicep deployment run: >- az deployment group what-if --resource-group "$AZURE_RESOURCE_GROUP" --template-file infra/main.bicep --parameters infra/environments/dev.bicepparam

IDs are environment configuration rather than passwords, but keep repository variables and scopes controlled. Pin third-party actions to reviewed immutable commits under high-assurance policy.

What does Azure DevOps add?

Azure Repos, Pipelines, Artifacts, Boards, Test Plans, and environment checks integrate with Entra and Azure. Use an Azure Resource Manager service connection configured for workload identity federation. Protect environments with approvals, branch control, required templates, and exclusive locks when needed.

Reusable YAML templates should enforce scanning, artifact publication, IaC preview, evidence, and deployment conventions. Product pipelines pass narrow parameters rather than copying security-critical steps.

How do application and infrastructure pipelines interact?

Infrastructure changes produce endpoints and identities; application deployment consumes non-secret outputs. Avoid a single job with subscription Owner that creates everything and ships arbitrary code. Separate duties and permissions:

  • Platform pipeline owns network, policy, shared registry, and clusters.
  • Workload infrastructure pipeline owns the app's cloud resources.
  • Application pipeline owns image/package and rollout.
  • Data migration pipeline has explicit database privilege and rollback plan.

What should block a release?

  • Unit/integration tests and contract tests.
  • Dependency, secret, code, image, and IaC scans.
  • Bicep what-if or Terraform plan review.
  • Policy compliance.
  • AI evaluation gates for prompt/model/retrieval changes.
  • Artifact provenance/signature verification.
  • Production approval and change window where required.
  • Health checks after progressive deployment.

Do not make a vulnerability scanner's “zero findings” the only release definition. Define severity, exploitability, exceptions, owner, expiry, and compensating controls.

How do you roll back?

Rollback application traffic to the previous healthy slot/revision/image digest. Roll forward infrastructure/data when destructive rollback is unsafe. Use backward-compatible database migrations. Keep feature flags separate from deployment and test the kill switch.

Pipeline security checklist

  • Workload federation, no long-lived Azure secret.
  • Protected default branch and reviewed CODEOWNERS.
  • Minimal token permissions.
  • No untrusted PR code with production credentials.
  • Trusted, pinned actions/extensions.
  • Isolated runners for sensitive workloads where required.
  • Secrets masked and absent from command arguments/artifacts.
  • Deployment logs retained and access-controlled.
  • Separate non-production and production identities.

Official references

  • GitHub Actions for Azure
  • Azure Login action with OIDC
  • Azure Pipelines documentation
  • Workload identity federation service connections