CI/CD pipelines
Twenty changes a day
Remy's team now merges about twenty changes a day into Shard Garden. Any one of them could break the garden for the players inside it.
A pipeline is the robot that checks and ships every change the same way, every time, so nobody has to remember the steps.
CI, then CD
Martin Fowler describes continuous integration (CI) as a practice where each member of a team merges their changes into a codebase "together with their colleagues changes at least daily". Every merge is built and tested automatically.
Continuous delivery goes further: "the product should always be in a state where we can release the latest build." Continuous deployment means "the product is automatically released to production", with no human step.
Quick check
Remy wants every change that passes the tests to reach players, with no human step. Which one is that?
- Continuous deployment
- Continuous delivery
- Continuous integration
Show the answer
Continuous deployment
Continuous delivery keeps every build ready to release. Continuous deployment actually releases it, automatically.
Jobs in a row
In GitHub Actions, a workflow is made of jobs, which "run in parallel by default". Each job runs on a machine named by runs-on.
To make one job wait for others, it lists them under needs. Shard Garden's pipeline tests and builds side by side, then deploys only when both have passed.
Keep it under ten minutes
Fowler calls "the XP guideline of a ten minute build" "perfectly within reason". A slow pipeline makes people save up changes and merge them in big batches, and a big batch is harder to check when it breaks.
His practice list also says: "Fix Broken Builds Immediately". A red pipeline blocks everyone behind it.
Read the workflow
1jobs:2 test:3 runs-on: ubuntu-latest4 build:5 runs-on: ubuntu-latest6 deploy:7 needs: [test, build]8 runs-on: ubuntu-latest
Which two jobs can run at the same time?
- test and build
- build and deploy
- None: jobs always run one by one
Show the answer
test and build
Jobs run in parallel unless one needs another. deploy needs both test and build, so it waits for them.
Four numbers for delivery
DORA, a long-running research programme on software delivery, measures how well a team delivers software with numbers like these:
- Deployment frequency"The number of deployments over a given period."
- Change lead timeFrom a commit "to deployed in production".
- Change fail rateThe share of deployments "that require immediate intervention".
- Recovery timeHow long it takes "to recover from a deployment that fails".
Quick check
Of 40 deploys this month, 2 needed an urgent fix. Which number is that, and what is it?
- Change fail rate: 5%
- Deployment frequency: 2
- Change lead time: 40
Show the answer
Change fail rate: 5%
2 out of 40 deploys needed immediate intervention: 2 ÷ 40 is 5%, the change fail rate.
Where does it go?
A pipeline needs places to send a build: somewhere safe first, then the real game.
Bolt says: Next: dev, staging and production.
Fact-checked 12 October 2026
- Martin Fowler: Continuous Integration martinfowler.com
- GitHub Docs: Workflow syntax for GitHub Actions docs.github.com
- DORA: software delivery performance metrics dora.dev