Skip to main content

Real use cases + complete FAQ

Summary: CI/CD is not a theory — it is what allows Amazon to deploy every few seconds and Netflix to serve 250 million subscribers without interruption. This last lesson presents five documented use cases, explains when CI/CD is not a good fit, answers the 14 most frequently asked questions, and guides you towards your next step.

1. Use case 1 — Amazon and deployment by the second​

The most useful lesson: many teams want to "do it like Amazon" by installing a better CI tool. But Amazon's performance comes first from its decoupled architecture and its organization into autonomous teams. An excellent pipeline on a monolith where fifteen teams coordinate will never produce those numbers.

2. Use case 2 — Etsy, the cultural pioneer​

Why this case matters more than Amazon's numbers: Etsy demonstrates that the transformation is first cultural. Having a newcomer deploy on their first day is not a technical feat — it is a statement about the reliability of the system and the trust placed in people.

3. Use case 3 — Netflix and embraced chaos​

4. Use case 4 — A European bank in a regulated sector​

This case is more representative of what you will encounter than the tech giants.

The essential lesson: regulatory compliance is not an obstacle to CI/CD. It forbids continuous deployment, but continuous delivery is perfectly compatible — and even produces superior traceability compared with the manual processes it replaces. It is a very useful argument when facing a reluctant compliance officer.

5. Use case 5 — A five-person startup​

This is the most useful use case to remember for the majority of readers. A 40-line YAML pipeline, free, running in 4 minutes, delivers the bulk of the benefit of CI/CD. Netflix's sophistication solves problems you probably do not have.

6. When full CI/CD is NOT the priority​

To be nuanced honestly: in almost all these cases, continuous integration remains beneficial. What must be put into perspective is continuous deployment and sophisticated tooling. A simple "on every pull request, we build and run the tests" delivers immediate value in almost every context.

7. The 14 most frequently asked questions​

1. How long does it take to set up CI/CD?

It depends radically on the starting point:

  • Basic pipeline (build + tests on every pull request) on a modern project: half a day to two days.
  • Full continuous delivery (automated deployment up to staging, ready for production): two to six weeks.
  • Transforming a legacy system without automated tests: several months, and most of the work consists of writing the tests, not configuring the tool.

The real cost is almost never the tooling. It is test coverage, backward-compatible migrations and team culture.

2. Do you need automated tests to do CI/CD?

For CI: yes, it is the very definition — automated validation is the heart of the practice. Without tests, you just have an automated build, which is already useful but very limited.

For continuous deployment: it is absolutely non-negotiable. The test suite is the only safeguard, since no human will review the result.

Good starting point if you are starting from zero: add tests on the critical paths (authentication, payment, account creation) rather than aiming for a global coverage percentage.

3. What test coverage should you aim for?

Be wary of the coverage metric. 90% coverage on trivial code is worth less than 60% on the critical paths.

Pragmatic reference points:

  • Less than 40%: the pipeline does not protect much.
  • 60 to 80%: comfort zone for most teams.
  • More than 90%: often a sign that useless things are being tested, except for critical software.

Better question to ask yourself: "if I deliberately break an important feature, does a test fail?". That is more revealing than any percentage.

4. My pipeline takes 45 minutes, how do I speed it up?

In decreasing order of impact:

  1. Parallelize the jobs — lint, unit tests and scan can run simultaneously.
  2. Cache the dependencies — node_modules, ~/.m2, ~/.cargo. Frequent gain: several minutes.
  3. Cache the Docker layers — with cache-from / cache-to.
  4. Split the tests — spread the suite over several runners in parallel (sharding).
  5. Reduce the end-to-end tests — they often dominate the total time. See the test pyramid in lesson 6.
  6. Do not run everything every time — on a monorepo, only test the affected modules (Nx, Turborepo, Bazel).
5. Where should I store my secrets?

In increasing order of quality:

  1. Never in the code or the pipeline file.
  2. The platform's secrets vault (GitHub Secrets, GitLab CI Variables) — acceptable minimum.
  3. A dedicated manager (Vault, AWS Secrets Manager) with rotation — good.
  4. OIDC federated identity — the state of the art: no long-lived secret exists. The pipeline presents a signed token, the cloud grants temporary rights.

If you should remember only one thing: aim for OIDC. It has become accessible on GitHub Actions, GitLab CI and the three major clouds.

6. Can you do CI/CD on a monolith?

Yes, absolutely. It is even simpler than with microservices in some respects: one pipeline, one artifact, one deployment to coordinate.

The real limits of a monolith are:

  • Slower pipeline — everything is rebuilt and retested on every change.
  • Maximum blast radius — a bug anywhere affects the entire application.
  • Team coordination — if fifteen people push to the same monolith, conflicts increase.

Do not migrate to microservices "to do CI/CD". That is a costly and frequent mistake. Improve your CI/CD on the monolith first.

7. CI/CD and databases: how do you handle migrations?

This is the trickiest point of CI/CD, and the one causing the most incidents.

Essential rules:

  1. Migrations are versioned code — Flyway, Liquibase, Alembic, Prisma Migrate.
  2. Always backward compatible — the previous version must keep working after the migration, because of the rolling update.
  3. Expand and contract pattern — add the new column, migrate the data, delete the old one in a later deployment. Never all at once.
  4. Test the migration on realistic data — an anonymized copy of production, not an empty database.
  5. Plan the way back — or design the migration so it never needs to be undone.

See lesson 4 for the details of the expand and contract pattern.

8. Do you need an engineer dedicated to CI/CD?

Depending on size:

  • Fewer than 10 developers: no. GitHub Actions or GitLab CI, someone handles it a few hours a month.
  • 10 to 50 developers: one person devotes 20 to 50% of their time to it.
  • More than 50 developers: a dedicated platform team becomes profitable — it provides reusable pipelines to the product teams.

Warning signal: if your developers spend more than 10% of their time fighting with the CI, the investment in someone dedicated is already profitable.

9. Are CI/CD and DevOps the same thing?

No. CI/CD is one technical practice among those of DevOps.

DevOps is much broader: a culture of shared responsibility between development and operations, observability, blameless incident management, infrastructure as code, automation, fast feedback loops.

Useful formula: "CI/CD is a pillar of DevOps, but doing CI/CD does not mean doing DevOps". A team can have an excellent pipeline and keep an impassable wall between developers and operators.

10. How do I convince my management to invest in CI/CD?

Speak in business consequences, not in tools:

  • Time to market — "our competitors ship in 2 days what we ship in 6 weeks".
  • Cost of incidents — quantify the time spent firefighting last month.
  • Cost of rollbacks — how much did the last failed deployment cost?
  • Talent retention — good engineers leave organizations where deploying is painful.
  • DORA references — the book Accelerate statistically establishes the link with profitability and market share. It is an argument that carries weight with management.

Effective tactic: measure your four DORA metrics, present them next to the "elite" thresholds, and propose a quantified three-month objective on a single metric.

11. Is CI/CD expensive?

Much less than you would think:

  • Open source project on GitHub: free and unlimited.
  • Small team, private repository: 0 to 50 € per month — the free quotas are often enough.
  • Medium team (20 developers): 100 to 500 € per month of runner minutes.
  • Large organization: from a few thousand to a few tens of thousands of euros per month, often optimized with self-hosted runners.

What to compare it with: the cost of a single day of incident in production frequently exceeds an entire year of CI bills.

12. What should you do when the pipeline is red on the main branch?

It is the team's absolute priority, before any other task. The canonical rule of continuous integration:

  1. Nobody pushes new code onto a broken main branch.
  2. The person who broke it fixes or reverts their change immediately.
  3. If the fix takes more than ten minutes, the commit is reverted (git revert) and fixed calmly in a branch.
  4. A light post-mortem if the breakage lasted a long time.

Common anti-pattern: leaving the main branch red "because we know why". Within a few days, the team stops looking at the status, and the pipeline no longer protects anything.

13. How do you test a pipeline locally?

This is a real weakness of all the tools, to varying degrees:

  • GitHub Actions: the act tool runs your workflows locally in Docker. Useful, but imperfect — some features are not reproduced.
  • GitLab CI: gitlab-runner exec lets you run a job locally.
  • Jenkins: jenkinsfile-runner, or more often a test Jenkins server.
  • Pragmatic and most widespread approach: a disposable branch named test-ci, on which you iterate with small commits until the pipeline passes. Not elegant, but effective.

Good design practice: put the real logic in scripts called by the pipeline. You then test the script locally, and the pipeline does nothing more than call it.

14. Where do I concretely start tomorrow morning?

Five-day plan, realistic for an existing project:

  1. Day 1 — Create a minimal pipeline that builds the project on every pull request. Nothing else.
  2. Day 2 — Add the linter and the formatter. Fix the existing warnings.
  3. Day 3 — Add the existing tests, even if they are few. Make the pipeline mandatory for merging.
  4. Day 4 — Add the Docker image build on the main branch, tagged with the commit hash.
  5. Day 5 — Add automatic deployment to the staging environment.

Then, the following week: measure your four DORA metrics to have a starting point. Continuous delivery to production will come later, once trust is established.

The principle to remember: start small and useful, not big and perfect.

8. What you have learned in this course​

You now have the complete CI/CD culture — the one expected for a DevOps interview, to talk with your team, or to arbitrate a tooling choice.

9. Your next step​

Path 1 · Complete your DevOps culture​

Path 2 · Move on to practice​

Path 3 · Act on your project this very week​

Take the five-day plan from question 14 above, and apply it to a real project. Even a personal repository is enough — what matters is typing the first line of YAML.

10. One last piece of advice​

The best pipeline is the one that exists. Many teams spend months designing the ideal CI/CD architecture and never deploy any of it. A twenty-line pipeline that builds and runs the tests on every pull request delivers immediately more value than a perfect plan left in a document.

Start tonight, on a project of your own. Add a .github/workflows/ci.yml file, with three steps. Watch the green check mark appear. That is how it begins.

Remember in 30 seconds​

  • Amazon deploys every few seconds — thanks to its architecture and its organization, not just its tools.
  • Etsy shows that the transformation is first cultural: every new employee deploys on their first day.
  • Netflix automates the canary with Spinnaker and deliberately causes failures (chaos engineering).
  • A regulated bank cannot do continuous deployment, but continuous delivery even improves its traceability.
  • A five-person startup gets the bulk of the benefit with 40 lines of free YAML.
  • Do not imitate Netflix if you do not have its problems. Complexity must answer a real need.
  • Start small: build and test on every pull request. The rest will come.

Thank you for taking this CI/CD discovery course! 🎉

Want to continue? Back to the table of contents or move on to the Premium GitHub Actions course.

Last step: take the end-of-course quiz — five corrected and explained questions, three minutes, to check that the essentials have been acquired.