What is the difference between Continuous Delivery and Continuous Deployment?
Both build on Continuous Integration and keep every change that passes the pipeline in a releasable state, but they differ in the final step. Continuous Delivery automates everything up to production and leaves the release as a manual, one-click business decision, so a human chooses when to ship. Continuous Deployment removes that gate entirely: every change that passes the full pipeline goes to production automatically, which demands a high-confidence test suite, progressive rollout, and fast automatic rollback because no human reviews the release.
How small should my commits and pull requests be for CI to work well?
Small enough to integrate at least daily, ideally many times a day. Continuous Integration only delivers its benefit - catching conflicts and breakages within minutes - when changes are merged to a shared mainline continuously, which is why trunk-based development favours tiny commits behind feature flags over long-lived branches. Large, long-running branches reintroduce the painful end-of-cycle merge that CI exists to eliminate, so the practical rule is to break work into the smallest change that keeps the build green.
When should I choose blue-green over canary deployment?
Choose blue-green when you want the simplest possible instant rollback and can afford to run two full environments during the cutover, since switching traffic back to the old environment is immediate. Choose canary when you want to limit the blast radius of a bad release by exposing it to a small fraction of traffic first and watching real metrics before widening, which catches problems blue-green's all-at-once switch would not. Canary needs good observability and a traffic-splitting layer; blue-green needs roughly double the infrastructure for the duration of the switch.
Why should build artifacts be immutable and built only once?
Building once and promoting the same artifact through every environment guarantees that the bytes you tested in staging are exactly the bytes you run in production, eliminating an entire class of "it worked in staging" defects caused by rebuilds picking up different dependencies. If each environment rebuilds from source, subtle differences in toolchain version, transitive dependency resolution, or build timing can change behaviour. The discipline is to produce a versioned, immutable artifact in CI and have CD deploy that exact artifact, referenced by content digest, everywhere downstream.
What are the four DORA metrics and why do they matter?
The four DORA metrics are deployment frequency and lead time for changes, which measure throughput, and change failure rate and mean time to recovery, which measure stability. They matter because years of research show that elite-performing teams score well on all four at once, disproving the belief that you must trade speed for stability. They give a team an objective, research-backed yardstick for whether process changes are actually improving delivery rather than just feeling faster.
How do I keep secrets out of my CI/CD pipeline and Git history?
Never commit secrets to the repository; store them in a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or your CI provider's encrypted secret store) and inject them into the pipeline at runtime as masked environment variables. Add secret-scanning to pre-commit hooks and CI so an accidental commit is caught before it merges, and treat any secret that has touched Git history or a build log as compromised and rotate it immediately. Prefer short-lived, automatically rotated credentials and OIDC-based federation over long-lived static keys so a leak has a small window of usefulness.
What is GitOps and how is it different from a normal CD pipeline?
GitOps makes Git the single source of truth for the desired state of your infrastructure and applications, with an in-cluster agent (Argo CD or Flux) continuously pulling that state and reconciling the live system to match. The key difference from a traditional push pipeline is direction and drift handling: instead of CI pushing changes into the cluster, the cluster pulls from Git, and any manual drift is automatically detected and corrected back to the declared state. This gives you a complete audit trail in Git history, easy rollback by reverting a commit, and a self-healing system.
How do I achieve zero-downtime deployments?
Bring new instances up and confirm they pass readiness checks before draining and removing old ones, using a rolling update, blue-green, or canary strategy behind a load balancer that respects connection draining. The harder half is the database: schema changes must be backward compatible so old and new application versions can run simultaneously during the rollover, which is why the expand-then-contract pattern (add the new column, deploy code that writes both, backfill, then later remove the old column) is the standard approach. Accurate readiness and liveness probes are what let the platform make safe traffic decisions automatically.
What belongs in a good health check endpoint?
A health check should report whether the instance can actually serve traffic, not merely that the process is running. Kubernetes distinguishes a liveness probe, which restarts a hung process, from a readiness probe, which removes an instance from load balancing until its critical dependencies (database connection pool, required caches) are reachable, and a startup probe, which gives slow-booting apps time before liveness kicks in. A common mistake is making readiness depend on a non-critical downstream service, which causes cascading outages when that dependency blips, so scope each probe to what truly determines serviceability.
How do I make database migrations safe in a CI/CD pipeline?
Apply migrations as a discrete, versioned, idempotent step (Flyway, Liquibase, or your ORM's migrator) and design every change to be backward compatible so it can be deployed before the code that needs it and rolled back without data loss. Follow the expand-then-contract pattern: additive changes (new nullable columns, new tables) ship first and are safe to roll back, while destructive changes (dropping a column) happen only after no running code references them. Run migrations forward-only in production and test them against a production-like dataset in the pipeline, because a migration that locks a large table can cause an outage even when the SQL is correct.
What is "shift left" and what should I move earlier?
Shifting left means running quality and security checks as early as possible - on the developer's machine and in the pull request - rather than discovering problems late in a release. Practically, move linting, unit tests, dependency vulnerability scanning, secret detection, and IaC scanning into pre-commit hooks and the PR pipeline so defects are caught when they are cheapest to fix and the author still has full context. The goal is fast feedback: a developer who learns about a vulnerable dependency in their PR fixes it in minutes, whereas the same finding in a quarterly audit costs far more.
Should pipeline definitions live in the repository?
Yes. Pipeline-as-code files such as .github/workflows/ci.yml, .gitlab-ci.yml, or a Jenkinsfile should be versioned alongside the application code they build, so the pipeline evolves with the code, changes go through review, and you can reproduce exactly how any past commit was built and tested. Keeping pipeline logic in a UI or out-of-band configuration makes it invisible, unreviewable, and impossible to roll back with the code. Treating the pipeline as code also lets you reuse and test it like any other software.
How big should a container image be and how do I shrink it?
Smaller is better for pull time, attack surface, and density, so aim to ship only the runtime and the application, not the build toolchain. The primary technique is a multi-stage build that compiles in one stage and copies only the finished artifact into a minimal final stage based on a slim or distroless image. Order Dockerfile instructions from least to most frequently changing to maximize layer-cache reuse, avoid installing unnecessary packages, and never bake secrets into a layer, because layers are individually extractable.
What is the difference between observability and monitoring?
Monitoring collects and alerts on a predefined set of signals to detect known failure modes - "is CPU high, is the error rate above threshold?" - and is essential but bounded by what you thought to watch. Observability is the broader property of being able to ask new questions about your system's behaviour from its outputs (metrics, logs, and traces) without shipping new code, which is what you need to diagnose novel, unforeseen problems. In practice you build monitoring on top of observable systems: rich instrumentation enables both the dashboards you predefined and the ad-hoc investigation you did not.
How do I roll back a release quickly and safely?
The fastest rollback is a planned one: deploy immutable, versioned artifacts so reverting means redeploying the previous known-good version, and prefer strategies with built-in rollback such as blue-green (switch traffic back) or GitOps (revert the commit). The complication is always state - a release that ran an incompatible database migration cannot simply roll the code back - which is why backward-compatible, expand-then-contract migrations are a prerequisite for safe rollback. Rehearse rollbacks so they are routine rather than an improvised emergency, and wire automatic rollback to your smoke tests and canary metrics.
How do I secure my software supply chain in the pipeline?
Treat everything that goes into a build as untrusted until verified: pin dependencies by hash, scan them for known CVEs and license issues on every build (Software Composition Analysis), and generate a Software Bill of Materials so you can answer "are we affected?" within minutes when the next Log4Shell drops. Sign your build artifacts (Sigstore/cosign) and produce verifiable build provenance per the SLSA framework so consumers can prove the artifact came from your pipeline and was not tampered with. Lock down the build environment itself with least-privilege credentials and ephemeral runners, because the build system is a high-value target.