Run a mock round

A build artefact is the immutable output of a build: a container image, JAR, binary, or package. Versioning means each artefact has a unique, traceable identifier.

Why:

• Reproducibility: you can redeploy exactly the bits that were tested instead of rebuilding and hoping.
• Traceability: a tag tied to a commit and pipeline run lets you find what changed and who made it.
• Rollback: redeploying a previous artefact is fast and reliable.
• Promotion: build once, then move the same artefact through staging and production. Rebuilding per environment risks differences.

Practices:

• Tag with the commit SHA plus a semantic version.
• Store in a registry or artefact repository with retention policies.
• Sign and scan artefacts for supply-chain security.
• Never overwrite a released tag; immutability is the point.

docker build -t registry.example.com/api:$(git rev-parse --short HEAD) .
docker push registry.example.com/api:$(git rev-parse --short HEAD)

Avoid building on production hosts.

Stages and jobs structure a pipeline into ordered, parallelisable work.

• Stage: a logical phase such as build, test, or deploy. Stages run in order, and a later stage starts only when earlier stages succeed. Stages express the release lifecycle.
• Job: the actual unit of work inside a stage, running on a runner or agent. Jobs within the same stage can run in parallel. Each job has steps, scripts, and its own environment.

stages: [build, test, deploy]
test:
  stage: test
  script:
    - npm ci
    - npm test

For example, a test stage may run unit, integration, and lint jobs concurrently, and then a deploy stage runs only if all pass. Jobs can produce artefacts that later jobs consume. Some tools call these stages and jobs, while others use workflows and jobs, but the concept is the same: ordered phases and parallel tasks.

Treat the pipeline as production infrastructure with its own threat model.

• Secrets: never hardcode them. Use a secrets manager or OIDC federation so the pipeline gets short-lived credentials instead of static keys. Mask values in logs.
• Least privilege: pipeline roles should only deploy what they need. Separate build and deploy permissions.
• Supply chain: pin and verify third-party actions and base images, sign artefacts, and generate SBOMs. Scan dependencies and images for CVEs.
• Code review: protect main, require reviews, and prevent self-approval of pipeline changes.
• Isolation: run untrusted builds in ephemeral, network-restricted runners. Do not expose long-lived cloud credentials to fork pull requests.
• Audit: log who triggered what, and store pipeline logs immutably.

permissions:
  id-token: write
  contents: read

Rotate credentials, scan infrastructure code with policy-as-code, and verify provenance before deployment. Assume the pipeline is a high-value target.

Both build on continuous integration, but they differ in what reaches production.

• Continuous delivery: every change that passes automated tests is always in a deployable state and can be released on demand. The final step to production is a manual approval or a button press. Teams release frequently but keep human control.
• Continuous deployment: every change that passes the pipeline is deployed to production automatically, with no manual gate. This requires very high test coverage, strong monitoring, and fast rollback.

Both need:

• Automated build, test, and security checks.
• Versioned artefacts and reproducible builds.
• Feature flags to decouple release from deploy.
• Observability and alerting.

Continuous delivery suits regulated or high-risk systems, while continuous deployment suits mature teams with low-risk, high-frequency changes. The difference is only the final production gate.

Blue/green is a deployment strategy with two identical environments. Blue runs the current version, and green runs the new version.

Process:

1. Deploy the new release to the idle environment and run smoke tests.
2. Shift traffic to it, usually by switching a router, load balancer, or DNS.
3. If something breaks, switch traffic back to the old environment almost instantly.
4. Keep the old environment until the new one is proven, then reuse it for the next release.

aws elbv2 modify-listener --listener-arn arn:... \
  --default-actions Type=forward,TargetGroupArn=arn:...green

Benefits: near-zero downtime, fast rollback, and the ability to test in production-like conditions. Drawbacks: double the infrastructure cost and tight data or schema compatibility between versions. It works best with stateless services and backward-compatible database migrations.

Make rollback a first-class, automated, and tested operation.

• Immutable artefacts: deploy versioned images or packages so you can redeploy the previous one exactly.
• Deployment strategies: use blue/green or canary so you can shift traffic back instantly. For Kubernetes, kubectl rollout undo reverts a Deployment.
• Database changes: use expand-and-contract migrations. Add columns and backfill first, make code compatible with both schemas, then remove old columns in a later release. Never ship a destructive migration with the code that needs it.
• Health checks and gates: automated verification after deploy, such as smoke tests and canary analysis, with automatic abort on failure.
• Feature flags: disable a feature without redeploying.
• Observability: alert on SLOs so you detect regressions quickly.

kubectl rollout history deployment/api
kubectl rollout undo deployment/api --to-revision=3

Practice rollbacks in game days; an untested rollback path is not a real safety net.

A canary releases the new version to a small slice of traffic before a full rollout.

Process:

1. Deploy the new version alongside the stable one.
2. Route a small percentage of traffic, for example 5 percent, to the canary.
3. Monitor error rates, latency, and business metrics.
4. If healthy, gradually increase traffic; if not, route everything back to stable.

kubectl set image deployment/api api=api:2.0
kubectl rollout pause deployment/api

Canary is often implemented with a service mesh such as Istio, an ingress controller with weights, or a feature flag. It limits blast radius and gives real-user feedback.

Requirements: good observability, comparable metrics between versions, and automation to promote or abort. Unlike blue/green, canary runs both versions simultaneously, so ensure compatibility and avoid session affinity issues.