A slow pipeline is one engineers route around
When builds are slow, flaky or hard to read, engineers merge around them and the controls go with them. Run the pipeline as a production system: fast first, then correct, with failures anyone can read.
The fastest way to lose the benefits of a delivery pipeline is to make it slow. When a build takes forty minutes and fails intermittently, engineers stop trusting it, start merging around it, and every gate you carefully built becomes optional. Pipeline reliability is not a nice-to-have; it is the thing that keeps the controls in the path.
Fast, then correct, then everything else
Order the stages so the cheapest, most likely-to-fail checks run first. A developer who has broken formatting should learn that in fifteen seconds, not after a ten-minute integration suite.
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22, cache: npm }
- run: npm ci
- run: npm run typecheck # cheap, fails fast
- run: npm run lint
- run: npm test # slower, runs only if the above passCache the expensive, deterministic steps
Dependency installs and build outputs are deterministic for a given lockfile. Cache them on the lockfile hash and a warm pipeline drops from minutes to seconds — which is what makes running it on every push tolerable.
Make failures legible
A red build that does not say why is worse than no build. Surface the failing step, the command, and the relevant log lines at the top of the output. The measure of a pipeline is not how often it is green — it is how quickly a red one tells you what to fix.
A gate teams trust is a gate teams keep. A gate they do not trust is a gate they remove.
NinetyX DevSecOps Practice
DevSecOps & Delivery
Engineers who put security and quality checks inside the delivery pipeline as gates. They write about keeping releases fast while every control stays in the path.
Where to next
Put the security checks inside your pipeline
We set up CI/CD pipelines where scans, policy checks and release evidence run as gates on every change, defined in your repositories and owned by your team.
See the DevSecOps servicesRelated articles
Security checks in the pipeline, tuned to real risk
A security review at the end of delivery comes too late to change much and turns into a queue. Scans and policy checks on every change give fast feedback, provided each gate blocks real risk.
NinetyX DevSecOps Practice · · 2 min read
Governed data comes before useful AI
AI work stalls in the data layer far more often than in the model. A catalogue, access granted at the source and lineage you can query are the groundwork most plans leave out.
NinetyX Data & AI Practice · · 2 min read
Treat LLM features as engineering, not experiments
Useful LLM features depend less on model size than on retrieval over your own content, an evaluation set that gates each release, and guardrails tested like any other code.
NinetyX Data & AI Practice · · 2 min read