Skip to content

Infrastructure & Integrations

CI/CD and release engineering: one path for every change, and a way back

In a lot of small businesses, releasing software means one person, late at night, following steps from memory and hoping. When something breaks, putting it back is another late night. Every change we make takes the same path: built, tested, previewed, reviewed and released, with the previous version kept ready. If errors rise, it's switched back in a minute, and the fix takes the same path.
Talk through how you releaseSee the path ↓
change · add Westfield to the service areasv43built2 minbuild412 passedtestslink readypreviewoffice managerapprovedreviewadds a columnv42 still worksdatabase change10:02releaseproductionrunning nowv42v43v42v44v43booking errors 0 → 14 in 3 min10:02v43 released: Westfield added to the service areas10:05booking errors 0 → 14 in 3 min · lead developer alerted10:06switched back to v42 · bookings working again10:35fix for Westfield's map area · v44 through the same path10:48v44 released · no errors

The path every change takes

The same stages for a one-word fix and a new feature. The small ones just go faster.

  1. 01

    Built

    From the code's history, by a machine

    Never from someone's laptop, so what's tested is exactly what's released.

  2. 02

    Tested

    Automatically, on every change

    The rules that matter most, checked before anyone looks at it.

  3. 03

    Previewed

    Its own address, sample data

    Anyone can try the change on their own phone before it reaches customers.

  4. 04

    Reviewed

    By a person

    Another developer reads the code; the person who asked for the change tries the preview.

  5. 05

    Database changes made safe

    The old version keeps working

    Changes are made in steps both versions can live with, so switching back never breaks the data.

  6. 06

    Released, watched, undoable

    The last good release kept ready

    Errors are watched after each release, and switching back takes a minute.

What's checked before release

Each check runs on every change. A failed check stops the release; nobody has to remember to look.
Testsa booking rule or a price calculation broken by the changeyes
Types and formattingmistakes the computer can spot before anyone runs the codeyes
Page speed budgeta page that got slower than its budgetyes
Accessibility checksmissing labels, unreachable buttonsyes
Package checka package with a known flawyes, until it's updated
Preview reviewanything the checks can't seeuntil a person approves

Three changes, one path

The path doesn't change with the size of the change. How long each stage takes does.

Fix a typo on the plans page

  1. Built and tested

    4 minutes

    done

  2. Preview

    office manager checks the wording

    done

  3. Database change

    not needed

  4. Released

    same afternoon

    done

Twenty minutes start to finish, through the same checks as everything else.

Released by hand, or by pipeline

Released by hand

  1. 01Steps followed from memory
  2. 02Tested if there's time
  3. 03Database changed directly
  4. 04Undoing it is another late night

Releases get rarer and bigger, so each one is riskier.

Released by pipeline

  1. 01The same stages for every change
  2. 02Tests and checks on every change
  3. 03Database changes the old version can live with
  4. 04Switched back in a minute

Releases get smaller and more frequent, so each one is safer.

What the pipeline connects

In

Changes
from the code's history
Checks
tests, speed, access, packages
Review
a person tries the preview
Pipeline
build, test, preview, release

Out

Releases
to each environment
Release record
what, when, who
A way back
the last good release

Worth setting up from the first release

Good fit

  • Releases are rare, late and nerve-racking.
  • Something broke last time and took hours to undo.
  • More than one person changes the software.

Not the right fit

  • A site built and edited in a website builder. The builder handles releases.
  • A throwaway prototype. Though the first real version should start with a pipeline.

Where this capability is used

Next to CI/CD

Questions about CI/CD and release engineering

What does CI/CD stand for?

Continuous integration and continuous delivery. In plain terms: every change is built and tested automatically, and can be released at any time through the same steps.

How often should we release?

As often as there's something worth releasing. Small, frequent releases are easier to check and easier to undo than big ones.

Can we approve releases ourselves?

Yes. The preview review can be anyone you choose, like the office manager for changes to booking. Nothing reaches production until they approve it.

What if switching back isn't possible?

Occasionally a change can't simply be undone, like a message already sent to customers. Those changes are planned in smaller steps, released at a quiet time and watched closely.