Skip to main content

Deployments

Deployments is the Deployments tab at /<workspace>/code — the surface that tracks every release across your repositories: which CI runs are green, which PRs are open, what's behind the default branch, and what's currently rolling out. Most of what shows up here is sourced live from GitHub Actions and your repos' branch state, so the page is the single mirror of "what's happening in CI/CD right now" without you needing to flip between tabs.

📷 Screenshot: Deployments tab with one repo expanded, runs and PRs side-by-side.

Per-repository accordions​

Repos are grouped by domain (frontend / backend / infrastructure / …) and rendered as accordions. The accordion summary surfaces the current state at a glance:

  • Action required chip when the latest completed run failed — clicking it deep-links to the failing run on GitHub.
  • Deploying chip when any in-progress or queued run is named deploy*.
  • PR count chip showing how many PRs are open against the repo (clicking it navigates to the GitHub /pulls list, or directly to the single PR if there's only one).
  • Behind by chip when the working branch is behind the default branch — useful for noticing stale long-lived branches before they conflict.
  • Last updated timestamp of the most recent run.

A repo accordion is considered active (sorted to the top, expanded by default in some views) when any of those chips fire. Quiet repos collapse out of your way.

Inside an accordion​

Expanding a repo opens a tab strip:

  • Runs — the latest GitHub Actions runs, with status (queued / in_progress / completed), conclusion (success / failure / cancelled / skipped), trigger (push / PR / scheduled / manual), and a link out to the run logs on GitHub.
  • Pull Requests — open PRs with review status, comment count, mergeable state, and direct links. PRs from agents are flagged so you can tell which ones to expect to self-update.
  • Branch comparison — what's on the working branch vs. the default branch (commits ahead / behind), so you can decide whether to merge, rebase, or open a sync PR.

Promotion and rollback​

Deployments themselves run through your GitHub Actions workflows — AI Expedite doesn't replace your deploy pipeline, it observes and orchestrates around it.

  • Canary status is surfaced from the workflow output when your deploy job exposes it (e.g. wait-for-drain, soak-check). Live progress streams into the run row above its eventual conclusion.
  • Auto rollback triggers when a post-deploy health check fails — the platform calls the rollback workflow on the previous revision and posts the result as a Monitoring incident plus an Inbox notification.
  • Manual rollback is one click on a completed run; it fires the same workflow with a flag.

The agent that owns a feature watches deployment outcomes and adjusts: a failed canary can move the Roadmap card back from Complete into In Progress with the failure context attached, so the next iteration starts with a real diagnosis instead of a blank slate.

How Deployments connects upstream​

  • From Tests — a run only enters the deployment phase if its test gate is green; failed runs surface here with the same "Action required" chip pointing at the failing job.
  • From Roadmap — a Kanban card in Review moves to Complete when the deploy run for its commit succeeds; it stays in Review otherwise, so the board reflects real shipping state, not just merge state.
  • To Monitoring — every deploy emits a marker on the Monitoring tab's timeline so you can correlate metric / error movement with releases at a glance.