The Bastion: A CI/CD Procedure for Shipping Bold Software, Safely

The pattern I keep seeing

After thirteen years architecting systems across companies of every size, from startups to scale-ups to enterprise, I keep seeing the same broken CI/CD pattern.

Teams ship slow. Teams ship scared. Sometimes both.

They have pipelines. They have tests. They have on-call rotations. They have Slack channels named #deploys. They still cannot reliably ship.

What is missing is not tooling. What is missing is a procedure. A defended structure that turns shipping software from a series of brave decisions into a repeatable, observable, improvable practice.

I built one. It is called The Bastion.

Why "bastion"?

A bastion, historically, is not a place that refuses activity. It is where activity happens safely, behind walls strong enough that the people inside can move with confidence. The walls exist so the work inside can be bold, not because the work is fearful.

That is the mental model. The Bastion is what gives teams permission to deploy aggressively, because the procedure holds.

The four parts

The Bastion is built from four parts that work together:

1. The Manifesto. Five tenets and thirteen principles that define how the procedure operates. These are the laws.
2. The Five Pillars. The structural backbone of practice.
3. The Maturity Model. Five levels that let any team self-assess where they stand.
4. The Five & Five Metrics. Ten measurements that prove whether the procedure is working.

The Five Tenets

These are the trade-offs the Bastion makes explicit:

I. Procedure over heroics.
II. Automation over approval.
III. Small changes over big plans.
IV. Observability over hope.
V. Recovery speed over uptime promises.

The last one is the most contrarian. Most organizations promise "99.99% uptime" and then break it. The Bastion promises fast recovery instead of impossible perfection, and asks teams to design their procedure around that honesty.

The Thirteen Principles (highlights)

The full manifesto has thirteen numbered principles. A few that tend to land hardest with senior engineers:

#3. Batch size is the master variable.
Smaller diffs deploy safer. Always. No exception survives a real post-mortem.

#5. Every gate is automated. Every override is logged.
Manual gates become bottlenecks. Override audit trails become culture.

#8. Rollback is a feature, not a fallback.
Rollback must be tested as rigorously as deploy. An untested rollback is a story you tell yourself.

#10. Tools change. The procedure does not.
The Bastion is tool-agnostic. AI is the current implementation of several principles, not a principle itself.

#12. Deployment frequency is the integral of a team's trust in its own gates.
Slow teams rarely lack tools. They lack trust in their procedure. Build the trust, frequency follows.

The Five Pillars

Each pillar depends on the previous one. You cannot legitimately have safe progressive deploys (Pillar 4) without automated paths (Pillar 2). You cannot have automated paths without a defined contract for "ready" (Pillar 1). That dependency chain is what most CI/CD initiatives miss. They try to buy Pillar 4 maturity without earning Pillars 1, 2, and 3 first.

How code actually flows through this

The pillars are abstract. The day-to-day workflow is concrete. The Bastion's recommended shape, end to end:

• Trunk-based branching. One mainline (main). Feature branches off main, named feat/short-description, living one to three days. No long-lived develop branch.
• PR opens, contract fires. Required reviewers are determined by which files the PR touches. Comments must resolve. No self-approval.
• Merge triggers the pipeline. The artifact is built once, tagged with the commit SHA, and promoted by reference through environments. Same image runs in CI, staging, and production. Only configuration differs.
• Production rollout is progressive. 1% → 10% → 50% → 100%, with SLO checks between steps. Automatic rollback if metrics dip.
• Every deploy is logged. The release log answers "what SHA is in production?" in under thirty seconds.
• Hotfixes use the same pipeline. Faster, not different. No bypass path that skips the contract.

The Bastion prefers a small environment footprint: local, CI, staging, production. Most teams have more (dev, QA, UAT, pre-prod) and the principles still apply: same artifact in every environment, automated promotion, per-environment SLOs. For a full walkthrough of what these artifacts actually look like in YAML, see What the Bastion Looks Like in a Repo.

One question the principles raise but rarely answer: when exactly does "the artifact" come into existence? The Bastion answers this with the single-artifact workflow. The artifact is built when an engineer pushes to a feature branch, the per-PR preview environment deploys that same artifact, and a merge queue promotes it through staging into production without rebuilding. What QA tested is byte-identical to what ships. The full mechanics (linear history, reproducible builds, merge queue, the eighteen-step lifecycle) are in the technical post.

The Maturity Model

Every team starts somewhere. The Bastion uses five named levels. Each one is a state a team can plausibly occupy, with observable signals.

Most teams self-assess at Level 3. Most teams, when validated honestly, are at Level 1 or 2 in at least one pillar. The gap between perception and reality is itself the most important diagnostic finding.

The Five & Five Metrics

The Bastion does not reinvent measurement. It accepts that the DORA metrics are already industry standard, then adds five Bastion-specific health metrics that measure the procedure itself.

Outcome metrics (DORA-aligned)

1. Deployment Frequency
2. Lead Time for Changes
3. Change Failure Rate
4. Mean Time to Restore (MTTR)
5. SLO Attainment

Health metrics (Bastion-specific)

6. Bastion Maturity Index (BMI). Sum of pillar levels (5 to 25)
7. Override Rate. Percent of deploys bypassing a gate
8. Median PR Size. The batch-size principle, made measurable
9. Rollback Success Rate. Percent of rollbacks completing without manual intervention
10. Repeat Incident Rate. Percent of incidents sharing root cause with one in the prior 12 months

Override Rate is the most undervalued metric in CI/CD. It is the leading indicator of every Change Failure Rate increase that comes later. Most teams have never measured it. Once they do, they tend to discover that what they called "automation" was actually "ceremony with a bypass switch."

What to do on Monday morning

If this resonates, here are three concrete moves you can make this quarter:

When those three are done, you are no longer on Open Ground. You are inside the walls.

What's next

This is the first post in what will become a series on The Bastion. Future posts will cover each pillar in depth, the full assessment methodology, and case studies from teams adopting the procedure.

If you want to discuss applying The Bastion to your team's CI/CD practice, or if you have a strong opinion about one of the principles, I would love to hear from you.

← Back to blog