Why I Built a Release Visibility Layer Instead of Another CI/CD Tool

WatchTurm — Sat, 21 Feb 2026 00:42:16 +0000

Modern engineering teams don’t struggle with automation anymore.

We have:

CI/CD pipelines
GitOps
Infrastructure as Code
Deployment dashboards
Observability tools

And yet, one simple question is still surprisingly hard to answer:

What is actually running in each environment right now?

Not what should be running.
Not what the pipeline says was deployed.
What is actually there.

The problem I kept seeing

In multi-repository environments with multiple stages (DEV, QA, UAT, PROD), release visibility becomes fragmented.

You end up checking:

GitHub for merged PRs
CI tool for build numbers
Deployment logs for environment history
Jira for scope
Slack/Teams for context

There is no single control perspective.

Over time, this leads to what I now call the release visibility gap:

Environment drift becomes normal
Release managers operate reactively
Production state is inferred, not verified
Slack becomes a source of truth

Nothing is “broken”.
But clarity is gone.

Why I didn’t build another pipeline tool

There are already great CI/CD tools.

The issue isn’t automation.
The issue is control above automation.

I wasn’t trying to:
replace pipelines
orchestrate deployments
enforce governance

I wanted one thing:

A consistent, aggregated, environment-level view of release state.

What I built:

I built WatchTurm, an open-source release visibility layer.

At a high level, it works like this:

Collect metadata from sources like:

GitHub
Jira
CI system (e.g., TeamCity)
Project configuration

Generate a single structured snapshot of:

versions
environments
linked changes

Surface that snapshot in a unified control view.

No magic.
Just a control layer.

The goal is simple:

No team should guess what is deployed.

What it is (and what it isn’t)

WatchTurm is:

A visibility layer
A structured release snapshot
A control perspective over environments

It is not:

A CI/CD replacement
A deployment engine
A governance enforcement tool

It’s designed to sit above automation, not inside it.

Why open source?

Because release visibility is not a competitive advantage.

It’s operational hygiene.

If more teams treat release control as infrastructure - not as a spreadsheet or Slack thread - we all benefit.

The bigger idea: Release Control

While building this, I realized something:

We optimized for speed.
We never formalized control.

That’s why I’m also documenting the thinking behind this approach under what I call Release Control - a discipline focused on:

What version runs where
How environments differ
What changed - and why

Not slowing delivery.
Making delivery accountable.

If this resonates

If you’ve ever asked:

“Is this really in production?”

“Why is QA different from UAT?”

“What exactly was included in this release?”

You’re probably dealing with the same visibility gap.

The project is open source here:

https://github.com/WatchTurm/WatchTurm-control-room

I’d love feedback, criticism, or ideas from people operating in similar environments.

DEV Community: WatchTurm

Why I Built a Release Visibility Layer Instead of Another CI/CD Tool