• 

  Issue-to-Production

• 

  Pipelines

• 

  Jobs

• 

  Tests

Issue-to-Production

From an Engineering Issue to an Evidence-Backed Release

Hackathon Path: Path A — New Project
Primary Track: Supervised Agent
Additional Track: Most Stages Covered

Inspiration

Software delivery has become increasingly automated, yet the journey from an engineering issue to a reliable release remains fragmented. An issue may be analyzed in one place, implemented in another, validated by a collection of CI jobs, and deployed through a separate process. When something fails, engineers must reconstruct what happened, identify the root cause, determine whether the release is safe, and decide how to recover.

AI coding agents make implementation faster, but generating code is only one part of software engineering. A genuinely useful agentic system must also understand the task, coordinate the necessary work, validate the outcome, respect release policies, and provide evidence that its decisions are justified.

That inspired Issue-to-Production: a GitLab-centered, agent-orchestrated software delivery system designed to connect engineering work with repeatable verification, controlled deployment, and recovery.

Our central principle is simple:

Let agents coordinate the work. Let deterministic policies control release safety. Let evidence establish what actually happened.

Rather than treating AI-generated code as automatically trustworthy, we wanted to explore how supervised agent workflows could work alongside conventional engineering safeguards to make software delivery more traceable, reproducible, and resilient.

What it does

Issue-to-Production combines GitLab Duo agent assistance, CI/CD automation, deterministic evaluation, release-readiness checks, staging verification, and recovery testing.

The system is built around five connected capabilities.

1. Understand the engineering task

The issue-analysis components assess a request's actionability, scope, risk, and complexity. Workflow state and reporting components provide structure for coordinating the work and communicating its status.

The objective is to begin with an engineering outcome, not simply an isolated code-generation prompt.

2. Coordinate agent-assisted engineering

GitLab Duo provides the agentic layer for planning, implementation assistance, code review, CI/CD troubleshooting, and release-readiness reporting.

The project targets the Supervised Agent track: agents assist with multi-step engineering tasks, while humans retain oversight of consequential actions and GitLab permissions constrain what can be executed.

The design distinguishes agent recommendations from verified results. A generated explanation is not a passing test, a proposed fix is not a validated change, and an agent's confidence is not a release approval.

3. Verify changes through CI/CD

The FastAPI application provides a concrete workload for repeatable engineering validation. Its issue-triage classifier categorizes requests as bug, feature_request, security, or documentation, using a multinomial Naive Bayes implementation.

Automated tests and deterministic evaluation check application behavior and model quality. The pipeline provides execution records and artifacts that engineers can inspect to understand what was tested and which conditions were satisfied.

4. Make release decisions deterministic

The release gate evaluates machine-readable evidence and produces three explicit outcomes:

• PROMOTE: configured release requirements are satisfied.
• HOLD: required evidence is missing or a release condition is unmet.
• ROLLBACK: a regression or release-blocking condition has been detected.

This separates AI assistance from release enforcement. The gate relies on configured rules and evaluation evidence rather than allowing an LLM to declare a release safe.

5. Verify staging and exercise recovery

The project includes controlled staging deployment, application health checks, regression scenarios, and recovery drills.

These checks address both sides of release safety: verifying that a healthy release can progress and testing that an unsafe or failed release does not proceed as intended.

The demonstrated staging environment uses local processes. It is a reproducible validation environment, not a claim of deployment to a production service.

How we built it

We built Issue-to-Production around a separation of responsibilities between agent orchestration and deterministic execution.

Application layer: A FastAPI service exposes the issue-triage functionality. A small, deterministic classifier makes application behavior straightforward to evaluate repeatedly.

Agent and workflow layer: GitLab Duo agents and flow configurations provide the foundation for planning, implementation assistance, review, CI/CD troubleshooting, and reporting. Supporting workflow modules model issue analysis, orchestration, execution state, and status reporting.

Verification layer: Automated tests and model evaluation establish repeatable checks. The pipeline records job outcomes and makes failures inspectable.

Release-control layer: A deterministic release gate evaluates the evidence and returns PROMOTE, HOLD, or ROLLBACK. Release-readiness reporting can bind results to a commit SHA and pipeline ID, connecting a decision to the code and execution that produced it.

Deployment and recovery layer: Controlled staging, health checks, regression scenarios, and recovery drills test whether the release process behaves as expected when conditions are healthy or degraded.

GitLab is central to the engineering workflow: the repository, pipeline history, CI jobs, agent configuration, and execution records provide a shared place to inspect the implementation and its evidence.

An important architectural decision was to avoid making release safety dependent on an LLM's free-form judgment. Agents can investigate and recommend; deterministic controls evaluate the configured release conditions.

DevSecOps lifecycle coverage

The Most Stages Covered track rewards meaningful breadth across the post-code DevSecOps lifecycle. Issue-to-Production is designed to address multiple stages through agent assistance, CI/CD, release controls, and recovery—not merely through a code-generation demonstration.

Lifecycle stage	Project contribution
Plan	Issue analysis, scope and risk assessment, and workflow planning assistance
Create	Application implementation and agent-assisted engineering
Verify	Automated tests, deterministic model evaluation, regression scenarios, and release gates
Package	Container definition and smoke-test validation
Secure	A relevant integration point for security scanning and policy enforcement; complete security-stage coverage requires verified security jobs and enforcement evidence
Release	Evidence-based release decisions and gated staging deployment
Configure	Controlled staging configuration; automated cloud infrastructure provisioning is not claimed
Monitor	Application health checks and recovery verification; continuous production observability is not claimed
Govern	Deterministic release rules, repository guardrails, and permission-constrained actions

The design aims for broad lifecycle coverage while recognizing that mentioning a stage is not the same as implementing it. Security scanning, continuous monitoring, infrastructure provisioning, and organization-wide governance require their own demonstrable integrations before they can be counted as fully covered.

Our approach is to make each stage observable and verifiable, with evidence showing which activities actually execute.

Challenges we ran into

Separating agent reasoning from release authority

An agent can produce a convincing explanation even when the underlying change is incorrect. We therefore designed the release gate around deterministic rules and machine-readable evidence instead of relying on an agent's conclusion.

Making release evidence traceable

A test result is more useful when it can be associated with the exact code and pipeline that produced it. Binding readiness reports to commit and pipeline identifiers helps reduce ambiguity when reviewing a release decision.

Testing failure paths, not just success

A pipeline that passes under healthy conditions does not prove that the system handles regressions safely. Regression scenarios, blocked-release behavior, staging checks, and recovery drills help exercise those less obvious conditions.

Coordinating a multi-stage workflow

Issue analysis, implementation, testing, review, deployment, and reporting have different requirements and permissions. Coordinating them requires explicit state, clear boundaries, and a distinction between planned actions and actions that have actually completed.

Distinguishing intended autonomy from demonstrated automation

Configuring an agent or writing an orchestration module does not prove that the entire workflow runs automatically. Trigger behavior, independent review, merge-request execution, duplicate-run handling, and policy-controlled actions must be verified through actual GitLab execution evidence.

This distinction shaped the project's emphasis on traceability and honest reporting: an intended capability should not be presented as a completed one.

Accomplishments we're proud of

We are proud of building a concrete delivery workflow around the idea that AI-assisted engineering should be measurable, controlled, and recoverable.

• Deterministic release decisions: Explicit PROMOTE, HOLD, and ROLLBACK outcomes make the release policy understandable and testable.
• Repeatable validation: Automated tests and deterministic evaluation provide a consistent basis for assessing changes.
• Evidence-bound reporting: Commit and pipeline identifiers help connect release-readiness decisions to their execution evidence.
• Negative-path testing: Regression, blocked-deployment, and recovery scenarios exercise failure behavior rather than assuming the happy path is sufficient.
• Controlled staging verification: Deployment checks and health probes validate the application in a reproducible local environment.
• GitLab-centered engineering: Repository contents, CI jobs, pipeline history, and Duo configuration make the implementation inspectable.

In a previously reported execution, pipeline #2967305719 completed successfully with 311 passing tests and reported successful release evaluation, staging, recovery, blocked-deployment, and container smoke checks. These are historical results from that execution, not a claim about the current pipeline or a guarantee of real-world classifier performance.

The evaluation dataset is small and synthetic, so perfect reported metrics must be interpreted within that limitation.

What we learned

AI autonomy is not the same as reliable delivery. A useful agentic workflow needs clear boundaries, observable state, and deterministic checks around its most consequential decisions.

Passing tests and release readiness are related, but different. A release decision should consider the configured evidence requirements, not just whether one test command succeeded.

Failure handling must be designed and exercised. Recovery behavior is more credible when it is tested through repeatable scenarios instead of being described as a future possibility.

Traceability improves engineering confidence. Connecting reports to a commit and pipeline helps reviewers establish what was evaluated, what decision was made, and why.

Lifecycle breadth requires proof. Every claimed stage should correspond to a real activity, configuration, execution record, or artifact. A credible, evidence-backed stage is more valuable than an unsupported claim of complete automation.

What's next for Issue-to-Production

The next step is to strengthen the end-to-end orchestration and increase the number of lifecycle stages supported by verified integrations.

Our priorities are:

1. Verify the complete issue-to-change workflow: Demonstrate supported triggers, bounded execution, agent invocation, and traceable status updates.
2. Strengthen independent review: Connect implementation to a reviewable merge-request lifecycle, with required approvals and permissions enforced.
3. Prove fail-closed behavior: Exercise missing evidence, failed tests, duplicate triggers, and release-blocking conditions.
4. Expand security coverage: Integrate and demonstrate security scanning with explicit failure policies and evidence.
5. Improve operational visibility: Extend beyond basic health checks toward persistent monitoring and actionable failure reporting.
6. Broaden deployment configuration: Explore infrastructure configuration and deployment targets beyond local staging.
7. Make lifecycle evidence easier to inspect: Produce a clear mapping from each claimed DevSecOps stage to its actual GitLab jobs, configuration, and artifacts.

These improvements would move the system toward a more complete, supervised engineering workflow without weakening its safety boundaries.

Closing

Issue-to-Production explores a practical approach to agentic software delivery: use AI to coordinate engineering work, deterministic policies to constrain release decisions, and execution evidence to make outcomes verifiable.

By connecting issue analysis, implementation assistance, CI/CD validation, release gates, staging, and recovery testing, the project aims to make the path from an engineering request to a verified release more structured and trustworthy.

Agents assist. Policies protect. Evidence proves.

Path: A — New Project
Primary Track: Supervised Agent
Additional Track: Most Stages Covered

Built With

• agentic
• agents
• ai
• api
• automated
• automation
• ci-cd
• continuous-integration
• deployment
• devops
• docker
• duo
• engineering
• fastapi
• gitlab
• gitlab-ci-cd
• integration
• machine-learning
• python
• release
• rest
• security
• software
• testing
• workflow