Release Intelligence Control Tower

Inspiration

Teams often know how to review code, but still struggle to decide whether a change is safe to release. We wanted to build something that answers the production question, not just the merge question. The inspiration was to turn release approval from a manual opinion into a structured, explainable, and enforceable workflow inside GitLab.

What it does

Release Intelligence Control Tower evaluates whether a merge request is ready for release. It combines merge request context, changed files, test signals, rollback readiness, and historical deploy and incident data to produce a deterministic risk score and a final decision: approve, review, or block.

It posts a structured merge request note, can create a remediation issue when the change is not ready, and integrates with GitLab CI so a release_gate job can block risky or stale changes from progressing.

How we built it

We built the system around three layers.

GitLab Duo provides the orchestration layer. A custom flow collects merge request context, analyzes the change, checks test coverage signals, builds a normalized payload, and sends it to the evaluation service.

A Python FastAPI service running on Cloud Run acts as the decision engine. It applies deterministic scoring rules, uses BigQuery for deploy and incident history, and generates the final release recommendation. Vertex AI Gemini is used only to improve the explanation text, never to override the deterministic decision.

GitLab CI/CD provides the enforcement layer. Pipelines build and deploy the service, seed demo history, and run a release_gate step that validates whether the latest evaluation for a merge request is fresh and safe enough to proceed.

Challenges we ran into

The hardest challenge was the GitLab Duo flow runtime path. The flow and trigger were configured correctly, but sessions were failing before component execution because the workflow metadata arrived with an empty rootNamespaceId, which caused model-resolution failures and immediate session shutdown.

We also ran into a production persistence bug in the Cloud Run service. BigQuery rejected nested evaluation fields like top_risks and rollback_plan because JSON columns were being written with raw Python arrays instead of JSON-encoded values. That caused POST /api/v1/evaluations to return internal server errors until we traced it through Cloud Run logs and fixed the serialization layer.

Another smaller challenge was Cloud Run path behavior: /healthz looked correct in the app code, but Cloud Run reserved-path behavior made that endpoint unreliable externally.

Accomplishments that we're proud of

We built more than a prompt demo. The project has a real API, a deterministic scoring model, persistent release history, GitLab flow orchestration, remediation issue generation, and CI enforcement.

We are especially proud of the architectural separation of concerns. The AI layer helps gather context and explain results, but the release decision stays deterministic and policy-driven. That makes the system much more trustworthy for production workflows.

We are also proud that the project works as a release-readiness platform concept, not just as a code-review assistant. It evaluates rollback evidence, historical incidents, and release freshness, which are exactly the kinds of signals teams need in the real world.

What we learned

We learned that release readiness is a fundamentally different problem from code review. Good release decisions depend on operational context, historical memory, and policy enforcement, not just diff understanding.

We also learned that AI is most useful when it is placed inside a controlled system. Using an LLM for explanation and workflow assistance works well, but letting it own the final release decision would make the outcome much harder to trust and audit.

On the platform side, we learned a lot about GitLab Duo custom flows, Cloud Run deployment behavior, BigQuery JSON handling, and the practical challenges of getting an end-to-end agent workflow to operate reliably across GitLab and GCP.

What's next for Release Intelligence Control Tower

The next step is to make the GitLab Duo flow path fully production-stable so the end-to-end MR experience is seamless. We also want to expand the scoring model with richer release signals such as canary readiness, feature flags, schema migration risk, service ownership weighting, and pipeline artifact evidence.

Beyond the hackathon, we would like to add dashboards for release health, trend reporting across teams, and support for broader rollout policies. The long-term vision is a release control layer that helps engineering teams move faster while reducing production risk.

Built With

• ai
• bigquery
• cloud-run
• devops
• fastapi
• gitlab
• gitlab-ci
• gitlab-duo
• hackathon
• mlops
• platform-engineering
• python
• release-management
• vertex-ai