CI/CD pipeline guides — integrate automated testing into your deployment pipeline and ship with confidence.
Testing
Retrying failing tests is a controversial topic. Critics say it hides flakiness and trains developers to ignore failures. Proponents say some level of retry is pragmatic in distributed test environments. Both are right — the answer is about when and how you retry. The Case Against Retries Automatic retries mask flaky
Testing
You've identified a flaky test. You can't fix it right now — it's intermittent, the root cause isn't clear, and you have a release to ship. What do you do? Deleting the test loses coverage. Skipping it silently means the failure is invisible.
Testing
"It works on my machine" is one of the oldest complaints in software development. With tests, the equivalent is "it passes locally but fails in CI." This pattern has specific, identifiable causes — and fixing them systematically makes your test suite dramatically more reliable. Why CI Is
Testing
Snapshot testing works seamlessly in a local development environment but introduces specific challenges in CI/CD pipelines: snapshots may differ across operating systems, developers can't run jest -u in CI, and snapshot updates need to make it into the repository without blocking deployments. This guide covers the patterns
Testing
Compliance testing done manually, at audit time, is expensive and unreliable. Controls that worked in Q1 can break in Q3 when someone updates a middleware or changes an API. Automated compliance testing shifts the catch point to when code changes — cheap to fix — rather than when auditors arrive. This guide
Testing
Catching accessibility regressions in CI is straightforward once you pick the right tools and decide what to block on. The challenge is not technical — it's deciding your enforcement strategy: block on any violation, block on regressions from baseline, or track and report without blocking. This guide covers the
Unity
Running Unity tests locally is fine. Running them automatically on every pull request is how you actually catch regressions before they ship. Setting up Unity CI/CD is notoriously painful because of licensing, but GameCI makes it manageable. This guide covers a production-ready Unity testing pipeline using GitHub Actions and
Chaos Engineering
Most teams run chaos experiments manually — a team gathers, runs an experiment, watches dashboards, and documents findings. This works, but it doesn't scale. Manual chaos experiments happen infrequently, require coordination, and catch problems after code has already been deployed to production. Chaos engineering in CI/CD changes this.
Shift-Left Testing
Shift-left testing changes where quality lives in your delivery pipeline. Instead of discovering defects in staging or production, you find them in pull requests, local builds, and feature branches. CI/CD is the engine that makes this work at scale. This guide covers exactly how to wire shift-left testing into
Testing
Webhook failures in CI are some of the most frustrating bugs to debug. The test passes locally but fails in CI. The webhook arrives but nothing happens. Logs show 200 OK but the feature doesn't work. This guide gives you a systematic approach for diagnosing and fixing webhook
CI/CD
The Dagger Python SDK lets you write CI pipelines as ordinary Python functions. No YAML, no DSL — just Python. You can import Dagger functions like any library, test them with pytest, and run them locally with the same command that runs in CI. This guide focuses on practical patterns: running
CI/CD
Dagger.io flips the CI/CD model on its head: instead of YAML pipelines that are impossible to test locally, you write your pipelines in Python, TypeScript, or Go — and run them anywhere. The same pipeline runs on your laptop, in GitHub Actions, and in GitLab CI without modification. This