CI/CD Pipelines — CodePipeline vs Cloud Build vs Azure DevOps

The goal is simple: a developer merges code, and it shows up in production safely, without anyone SSH-ing into a server or clicking through a console. CI/CD pipelines automate the path from commit to running software, and the difference between a good pipeline and a bad one is the difference between deploying ten times a day with confidence and dreading every release.

CI vs CD vs Continuous Deployment

These terms get conflated constantly. Continuous Integration (CI) means every commit is automatically built and tested. The bar: does the code compile, do the tests pass, do the linters and security scanners agree it's acceptable? CI catches problems in minutes, not when someone manually tests a release candidate next Thursday.

Continuous Delivery (CD) means every commit that passes CI is deployable to production at any time. The artifact is ready; a human decides when to push the button. Continuous Deployment removes the human — every passing commit goes straight to production automatically. Most teams practice continuous delivery; continuous deployment requires excellent test coverage and robust rollback.

Pipeline Stages

A mature pipeline has these stages, in order:

Source — a commit or merge triggers the pipeline. Build — compile the code, resolve dependencies, produce an artifact (container image, binary, bundle). Test — unit tests, integration tests, and end-to-end tests at increasing scope. Scan — SAST (static analysis), dependency vulnerability scanning, container image scanning, IaC scanning. Artifact — push the built artifact to a registry (ECR, Artifact Registry, ACR) with an immutable tag. Deploy — roll the artifact out to the target environment. Verify — smoke tests, health checks, and metric validation against the running deployment.

Each stage is a gate. Failure at any stage stops the pipeline and notifies the team. No exceptions.

AWS Implementation

AWS provides a suite of CI/CD services. CodePipeline orchestrates the stages. CodeBuild runs builds and tests in managed containers. CodeDeploy handles deployment to EC2, ECS, and Lambda with blue-green and canary strategies. These integrate tightly with AWS services but are verbose to configure and less ergonomic than alternatives.

In practice, most AWS teams use GitHub Actions for CI and CodeDeploy or custom deploy scripts for CD. GitHub Actions has better developer experience, richer marketplace of actions, and OIDC federation to AWS removes the need for stored credentials. AWS's native tools are worth considering when you need deep integration with CodePipeline's manual approval stages or when governance requires everything to stay within AWS.

GCP Implementation

Cloud Build is GCP's CI/CD service — it's both the build system and the pipeline orchestrator. Configuration is a YAML file defining steps, each running in a container. It's simpler than AWS's multi-service approach but less feature-rich for complex pipeline orchestration.

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/myapp:$COMMIT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/myapp:$COMMIT_SHA']
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args: ['run', '--image=gcr.io/$PROJECT_ID/myapp:$COMMIT_SHA', '--cluster=prod']

Cloud Build integrates well with GKE, Cloud Run, and Artifact Registry. For more complex workflows, teams layer Cloud Deploy (managed delivery pipeline with promotion between environments) on top.

Azure Implementation

Azure DevOps is the most full-featured native CI/CD platform of the three providers. Azure Pipelines supports YAML-defined pipelines with multi-stage deployments, environment approvals, and deployment gates. It works with any cloud, not just Azure, and supports self-hosted agents for on-prem builds.

GitHub Actions (owned by Microsoft) is increasingly the default for Azure-native teams too. Azure provides first-party GitHub Actions for deploying to App Service, AKS, and Azure Functions, plus OIDC federation via federated credentials in Entra ID.

Side-by-Side Comparison

Aspect	AWS	GCP	Azure
CI/CD service	CodePipeline + CodeBuild	Cloud Build + Cloud Deploy	Azure Pipelines / GitHub Actions
Build environment	CodeBuild (managed containers)	Cloud Build (container steps)	Azure Pipelines (hosted agents)
Deployment service	CodeDeploy	Cloud Deploy / Cloud Build	Azure Pipelines environments
Container registry	ECR	Artifact Registry	ACR
OIDC federation	STS + OIDC provider	Workload Identity Federation	Federated credentials
GitHub Actions integration	Good (OIDC)	Good (OIDC)	Excellent (native)
Complexity	High (multi-service)	Medium (simpler model)	Medium-low (most integrated)

Deployment Strategies

How you roll out new code determines your blast radius and rollback speed.

Rolling deployment replaces instances gradually — old and new versions run simultaneously during the rollout. Simple and resource-efficient, but mixed versions serving traffic can cause subtle bugs if APIs aren't backward-compatible.

Blue-green deployment runs two identical environments. Deploy to the inactive one (green), verify it, then switch traffic from blue to green. Rollback is instant — switch back. The cost is double the infrastructure during deployment. Works well for stateless services.

Canary deployment sends a small percentage of traffic (1-5%) to the new version first. Monitor error rates and latency. If metrics look good, gradually increase traffic. If something's wrong, roll back with minimal impact. This is the gold standard but requires solid observability.

Feature flags decouple deployment from release. Code ships to production but the feature is hidden behind a flag. You enable it for internal users, then 1% of traffic, then everyone. This separates "deploy risk" from "feature risk" — extremely powerful.

Rollback: The Hard Part

Your rollback strategy matters more than your deploy strategy. Rolling back a stateless service is easy — point traffic at the previous version. Rolling back a database migration is the thing that makes everyone sweat.

The expand/contract pattern makes database changes safely reversible. Never rename a column in one step. Instead: (1) add the new column, (2) write to both columns, (3) backfill the new column, (4) read from the new column, (5) stop writing to the old column, (6) drop the old column. Each step is independently deployable and reversible. Yes, it takes four deployments to rename a column. That's the price of safe rollback.

Pipeline Security

OIDC federation replaces stored secrets. Your CI provider (GitHub Actions, GitLab) issues a token, and your cloud provider trusts it to assume a role. No access keys to rotate or leak.

Least privilege: the CI/CD role should only be able to deploy to specific services in specific environments. A pipeline that can modify IAM policies can escalate its own privileges.

Signed artifacts: sign container images (cosign/Sigstore) so you can verify in production that the image came from your pipeline, not from someone who pushed directly to the registry.

Protected branches: main/production branches require PR approval and passing CI before merge. No force-pushes. No bypasses.

Supply Chain and DORA

SLSA (Supply chain Levels for Software Artifacts) is a framework for artifact integrity. At higher levels, you have provenance — cryptographic proof of how and where an artifact was built. Provenance attestation lets you enforce that only artifacts built by your CI system run in production.

The DORA four keys measure engineering effectiveness: deployment frequency, lead time for changes, change failure rate, and time to restore service. Track these. They tell you whether your pipeline is a competitive advantage or a bottleneck.

Key Takeaways

• CI validates code automatically on every commit; CD ensures it's always deployable; continuous deployment removes the human approval step
• Canary deployments with metric-gated promotion are the gold standard — they limit blast radius while providing real production validation
• Rollback strategy matters more than deploy strategy; database migrations are the hard part, and the expand/contract pattern makes them reversible
• Use OIDC federation instead of stored credentials in CI/CD — no access keys means nothing to leak or rotate
• Sign your artifacts, protect your branches, and enforce that only pipeline-built images run in production
• Track the DORA four keys to measure whether your pipeline is accelerating or hindering your team

Next, we'll look at making sure all this infrastructure doesn't cost more than it needs to.