After this lesson, you will be able to: Compare Azure DevOps Pipelines to GitHub Actions, write a YAML-based pipeline, and decide when to use Azure DevOps vs GitHub.
Azure DevOps and GitHub Actions both belong to Microsoft. Knowing where each fits matters for jobs at Microsoft-heavy shops.
Azure Boards: agile work tracking. Azure Repos: git hosting. Azure Pipelines: CI/CD (the relevant piece here). Azure Artifacts: package feeds (npm, NuGet, Maven). Azure Test Plans: manual + automated test management. Mature, integrated, enterprise. Sold as a single product since 2018.
Same model: YAML in repo, hosted runners, marketplace of tasks. Azure Pipelines: older, more mature, better Windows / .NET ecosystem, free for OSS, $40/parallel-job/mo for private. GitHub Actions: newer, simpler UX, integrates with GitHub-first features (PRs, environments, OIDC), free quotas more generous. Microsoft owns both; strategy is to keep Pipelines for enterprise (cross-repo, multi-cloud) and Actions for GitHub-native projects. Most NEW projects pick Actions. Existing Pipelines projects stay.
Drop into the repo root. Same shape as GitHub Actions, different keywords.
# azure-pipelines.ymltrigger:branches:include: [main]pr:branches:include: ['*']pool:vmImage: ubuntu-latestvariables:NODE_VERSION: '20'stages:- stage: buildjobs:- job: build_and_teststeps:- task: NodeTool@0inputs: { versionSpec: $(NODE_VERSION) }- script: npm ci- script: npm run lint- script: npm test -- --run- script: npm run build- task: PublishBuildArtifacts@1inputs:pathToPublish: distartifactName: dist- stage: deploydependsOn: buildcondition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))jobs:- deployment: deploy_app_serviceenvironment: productionstrategy:runOnce:deploy:steps:- task: AzureWebApp@1inputs:azureSubscription: 'my-service-connection'appName: 'myapp-yourname'package: $(Pipeline.Workspace)/dist
Service connection = a stored credential / federated identity from Azure DevOps to a target (Azure subscription, AWS, GitHub, ACR). Modern best practice: Workload Identity Federation (OIDC), no stored secrets. Configure once per environment; pipelines reference by name.
Enterprise that already runs Azure DevOps (large code estates, audit, compliance). Complex pipelines across many repos (Azure DevOps has stronger cross-repo + multi-stage features). Mixed cloud (AWS + Azure) where you don't want GitHub Actions to be the orchestrator. Long-tail enterprise needs: Test Plans, manual approvals, Artifacts feeds. For new projects: GitHub Actions is the safer default. Knowing Azure DevOps is a job-market advantage at Microsoft shops.
Picking Azure DevOps for new GitHub projects. The integration is weaker than Actions in that case. Storing Azure credentials as variables. Use Service Connections (with OIDC where possible). No environment approvals on production deploys. Available in Azure DevOps; turn them on. Skipping templates. YAML repetition becomes unmaintainable; use templates + parameters. Forgetting the per-parallel-job cost on private projects.
Pick the pragmatic default.
Sign in and purchase access to unlock this lesson.