Release Sentinel

An agentic release-readiness copilot that correlates engineering signals to answer: is this build safe to ship?

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Release Sentinel

Inspiration

This was inspired by Codex review of development activities over the past 6 months and what would make a useful AI tool. Release Sentinel was discovered & built to answer the question that dashboards leave unresolved: is this build safe to ship?

What it does

Release Sentinel is an agentic release-readiness co-pilot. Select a release candidate and it brings together 6 engineering perspectives:

  • GitHub diff size, hotspots, migrations, and commit authors
  • TeamCity build status, duration, and muted tests
  • SonarQube quality-gate results and new-code findings
  • Datadog monitors and recent incidents
  • Jira version issues and unresolved blockers
  • Octopus Deploy history and available rollback runbooks

Click Assess release to receive a GO, GO_WITH_CAUTION, or NO_GO verdict; a 0–100 risk score; ranked blockers with evidence and recommended action; a summary of what changed; a concrete rollback plan; and the hotspot authors who can answer the most relevant questions.

How I built it

Codex built the project using Node.js 20: a small HTTP server, a JavaScript interface, and reasoning engine with a stable JSON contract. When an OpenAI API key is configured, GPT-5.6 receives cross-source evidence and returns release reasoning. Without a key—or if the request fails—the same endpoint falls back to a deterministic rules engine.

The dashboard includes 3 calibrated scenarios: a safe patch release, release that needs caution, and a correlated high-risk release. Automated tests pin their expected verdicts and scores.

Codex ran the full build loop: shaping fixtures, implementing the correlation rules and model prompt, writing tests, refining the UI, adding deployment hardening, and verifying each scenario in a real browser. It also deployed the demo to AWS EC2 behind systemd, Nginx, and HTTPS.

Challenges

The biggest challenge is lack of MCP server access to the various development processes - TeamCity, Octopus, JIRA for a given organisation. So the demo doesn't need the MCP server access.

What I learned

Codex can handle multiple MCP servers and bring the results back into 1 screen.

What's next

Live MCP server adaptors for each source, history, sign-offs, Teams delivery. Screen improvement to show status from each source.

Built With

Share this project:

Updates