Loading…
Systems / Build & Release Flow
NEW ON THE PLATFORMcalm · order
Build & Release Flow
Submit a change, scan it, you approve, then it ships with a log.
- What it is
- A fixed sequence: plan, change, test, you approve, then ship with a log.
- Typically gives back
- the cost of one “who changed this?” incident
- Replaces
- FTP-by-default and no audit.
What it costs you without this
Calm arithmetic, not fear. Methodology.
Changes go live because someone had the password. History is a guess.
Lab measurement
No human gate before merge or production — lab rule: no auto-deploy to client production.
Lab measurement
When it breaks, there is no session handoff — the next person starts blind.
Illustrative example
| Week | Month | At €40/h |
|---|---|---|
| 4 h | 16 h | €640/mo |
Illustrative: 4 h/week of firefighting × €40/h × 4 weeks
Illustrative composite example — 4 h/week firefighting ≈ €640/month at €40/h. One avoided incident often pays for the flow. Your scan sizes the real risk.
A firm like this
Meridian Parts
11-person company that had a “who changed this?” production incident
Without the system
- A Friday edit went live with no scan.
- Nobody could say which file moved.
- The next morning was archaeology.
With the system
- Work arrives as a proposal with a plan.
- Tests and secret scans run before the click.
- You approve. A handoff file closes the session.
| Metric | Before | After |
|---|---|---|
| Live without a click | Possible | Blocked |
| Hours/week firefighting | ~4 h (illustrative) | Log first |
| €/month at €40/h | €640 | Scan sizes the risk |
Illustrative composite example — not a real client
What is in the system
Only what we can point to. Missing pieces stay off this page.
Fixed specialist steps
Five roles in sequence: plan, change, test, review, close — not a free-for-all.
You see: Where the work is. Who waits on you.
One module per session
The change step is scoped to the target module — least privilege.
You see: A small diff, not a weekend rewrite.
Test report before review
Tests and logs are collected before you see the queue.
You see: Pass/fail, not a speech.
Human review pause
The pipeline stops at reviewing. Approve or block.
You see: A yes/no. Production stays yours.
Secret scan
Secrets and dependency checks before the change ships.
You see: A report, not a leaked key next week.
Queue with cost visibility
Lab operator view: queue, history, and a cost tab per task.
You see: What this change cost in time — not a mystery invoice.
Session handoff on disk
The close step writes a markdown handoff.
You see: The next person can continue.
No auto-deploy to your production
Shipping to client production is a human action.
You see: You still press the last button.
How it works
- 1. Submit the change as a proposal.
- 2. Build and scan.
- 3. You approve.
- 4. Release and log.
In the build
- Fixed five-step sequence (plan → change → test → approve → close)
- Scoped diffs — one module at a time
- Test report before your click
- Secret and dependency scans
- Approval log and session handoff
- No silent deploy to your production
- Documentation, scans, handover
- Your repository from day one
Good to know
It is a release habit: nothing live without a scan and a click. Not a department.
If you never change production and have no repo, start with the scan — this flow may be later.
No. Your production stays your click. The code lives in your repo.
Works well with
Start with the scan
90 minutes. Written report is yours. Then a fixed price — or a clear no.