Skip to content

Ship a change, and break one on purpose

Make a code change, push it, and watch it reach the server. Then see a failing test stop a bad release.

About 25 min · Verified 8 October 2026

0 of 10 steps done0%
On this page

Now the payoff. You will make a small API change, push it, and never touch the server. Then you will deliberately break a test to see the pipeline protect production.

Part 1: a change that ships#

The API's root route (GET /) currently returns a name and a status. You will add a version, and update the test that checks the exact response.

Create a branch#

Your computerWork on a branch, not on main
git switch main
git pull origin main
git switch -c add-api-version

Pushing a branch does not start the pipeline, because the trigger only listens to main. Only the merge will.

Change the code#

Open shortlink-api/src/app.js and find the root route:

shortlink-api/src/app.js
   app.get('/', (_req, res) => {
-    res.json({ name: 'shortlink-api', status: 'running' })
+    res.json({ name: 'shortlink-api', status: 'running', version: '1.1.0' })
   })

Update the test that describes the behaviour#

Open shortlink-api/tests/links.test.js, find the GET / test, and change the expected value:

shortlink-api/tests/links.test.js
     expect(res.status).toBe(200)
-    expect(res.body).toEqual({ name: 'shortlink-api', status: 'running' })
+    expect(res.body).toEqual({ name: 'shortlink-api', status: 'running', version: '1.1.0' })

toEqual compares the whole object, so a test that is not updated will fail. That is exactly the safety net you are about to rely on.

Run the tests locally#

Your computerTests must pass before you push
npm --prefix shortlink-api test
You should see
Tests: 36 passed, 36 total

Commit and push the branch#

Your computerCommit your change
git add shortlink-api/src/app.js shortlink-api/tests/links.test.js
git commit -m "feat(api): report version on the root route"
git push -u origin add-api-version

Check the CodePipeline console: no new execution. Good.

Merge into main#

Merge into your fork's main. The simplest way is locally:

Your computerMerge and push main
git switch main
git merge --no-ff add-api-version -m "Merge add-api-version"
git push origin main

Watch it deploy#

Within about a minute shortlink-api-prod starts a new execution on its own. Source shows your merge commit. Wait for Deploy to finish, then:

Your computerThe new version is live
curl -sS http://<ALB_DNS>/

Replace <ALB_DNS> with your own value (or fill in the known ones once under My values at the top of the page).

Expected output
{"name":"shortlink-api","status":"running","version":"1.1.0"}
You should see
The version appears in the response and you never opened a shell on the server.

Part 2: break the build on purpose#

A pipeline is only valuable if it stops bad code. Prove it does.

Change behaviour without updating the test#

Your computerA branch with a deliberately broken change
git switch -c break-on-purpose

In shortlink-api/src/app.js change the status text:

shortlink-api/src/app.js
-    res.json({ name: 'shortlink-api', status: 'running', version: '1.1.0' })
+    res.json({ name: 'shortlink-api', status: 'up', version: '1.1.0' })

Run npm --prefix shortlink-api test and watch the GET / test fail locally. Now push it anyway, straight to main for this experiment:

Your computerPush the broken change
git add shortlink-api/src/app.js
git commit -m "chore: change status text (will fail tests)"
git switch main
git merge break-on-purpose
git push origin main

See what the pipeline does#

Open the new execution. Build turns red, and in the CodeBuild log you see the failing test. Deploy never starts. Check production:

Your computerProduction still serves the old version
curl -sS http://<ALB_DNS>/

Replace <ALB_DNS> with your own value (or fill in the known ones once under My values at the top of the page).

The status is still "running". The broken commit exists on GitHub but never reached your server.

Fix it by reverting#

Your computerUndo the bad commit and push
git revert --no-edit HEAD
git push origin main

A new execution runs, the tests pass again, and the deployment succeeds. Reverting with Git is the safest way to undo, because it leaves a clear history and runs through the same pipeline.

Next: rollbacks and day-to-day operations.

Found a mistake? Edit this page on GitHub.