Deployments
Deployments are where the two halves of ACE meet. A pull request is the end of the Dev loop, but a merge is not the end of the story: the code still has to go out, and once it is running it becomes the concern of Operations, the DevOps half. The Deployments screen is the bridge between the two.
Feature Development turns a request into merged code. Operations keeps the running system healthy. Deployments is where a merge becomes something live to watch, which is why a failed run here can flow straight back into the board as tracked work.
What it tracks
The Deployments screen lists deployment runs reported by your connected CI/CD providers (GitHub Actions, GitLab CI, AWS CodePipeline, Azure DevOps, CircleCI, Jenkins, Bitbucket) as well as any other external event source you wire up through a webhook. While anything is still queued or running, the list refreshes itself so status changes show up on their own.
You can filter by status (Success, Running, Queued, Failed, Cancelled, Skipped), source, environment, and date. Each run opens a detail page showing its pipeline and run number, commit, environment, branch, duration, and status.
Analysis of a run
A deployment run has the same AI analysis panel as a pull request. You can run an analysis on demand, or have ACE do it automatically, and it hands back a plain-language report on what happened. On a failed run, that report is a running head start on the diagnosis.
Rules, per source
Deployment rules are set separately for each connected repository and for other event sources. Two independent toggles:
- Post pipeline lifecycle to communication channels: open a thread on the first event seen for a run, and reply when it reaches a final state. The in-between states stay quiet.
- Analyze failures automatically: run the agent only after a run ends in failure, and only for a matching branch or pipeline pattern.
A rule change applies to runs observed after the change. A run already in progress keeps the rules that were active when it started.
Crossing into Operations
This is the connective tissue in action. A deployment does not have to stay a passive record:
- Create Card turns a run into a card on the Development Board, pre-filled with its context, so a bad deploy becomes a tracked fix that re-enters the inner loop.
- Discuss in chat opens a conversation seeded with the run, so you can ask the AI what went wrong.
A signal from your deployment pipeline is also one of the sources that can raise an incident on its own. So a deployment can flow forward into Operations as something to watch, or backward into Feature Development as something to fix. Either way, it is the same platform and the same card lifecycle.