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.
Top comments (2)
This resonates. Curious — how do you handle services with very different release cadences?
Great question - and honestly, this is where most release models start to break down.
In practice, we don’t try to force synchronization. Services with different release cadences should stay decoupled. What matters is:
-clear promotion paths per service
-environment-level visibility
-traceable artifact movement (dev -> qa -> uat -> prod)
-explicit dependency awareness
WatchTurm doesn’t try to align cadences - it makes the differences visible
When you can see what version of each service is deployed where, cadence stops being chaos and becomes a controlled variable :)