N100FN100F
Published on

Let the build fail, not production

Everything that can be checked without human judgement should be checked before publishing, and if it fails, it should stop everything. Better a broken deployment with a clear message than an error in a user's hands.

Service line Platform Engineering

The review nobody does

Before publishing, somebody should check that every link works, that the images exist, that there are no secrets in the code, that the mandatory data is complete and that the configuration makes sense. Nobody does that by hand reliably, least of all on the fifth publication of the day.

The solution is not to review better. It is for the build to check it on its own and refuse to continue if something does not comply.

Validators in a chain

What the build stopsFive validation stages that stop 17 errors before production.PLATFORM · VALIDATIONWhat the build stopsFormatdates, mandatory fields7 stoppedReferencesimages and modules that exist3 stoppedLinksno broken internal link4 stoppedSecretsnothing shaped like a key1 stoppedOwn rulesnothing internal published2 stopped0 errors in productionEvery error says which file and which line: fixing takes minutes.What the machine cannot see (whether it reads well, whether it is right) is left to people.Illustrative data; they do not correspond to any real caseN100F · n100f.com

A governed build chains automatic checks, each with a message saying which file and which line fails:

  • Format: valid dates, mandatory fields present, values within what is allowed.
  • References: everything cited exists (images, modules, other documents).
  • Links: no internal link leads to a non-existent page.
  • Secrets: nothing shaped like a key or a password inside the code.
  • Own rules: the organisation's standards turned into checks (for example, that no internal working file ever gets published).

Breaking on purpose

The key is the attitude: the build fails on purpose. It does not warn and carry on; it stops. A warning gets ignored by the third day. A broken build forces a fix, and because the message says exactly where the problem is, fixing it takes minutes.

What the machine cannot validate

Automatic checks cover what is verifiable. They do not cover judgement: whether a text makes sense, whether a diagram explains what it should, whether a decision is the right one. That remains work for people, at the gates that belong to them. The advantage is that they arrive at that review without wasting time on what the machine has already checked.

Once in production, the question changes: it is no longer 'is it right?', but 'what exactly is running, and why?'.

How we apply it: Platform Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk