CoroidYour AI software factory
Documentation

Recovery and release trains

Respond to a failed deployment or health check, revert to a stable commit, and ship releases for multiple projects together.

When a deployment fails

A failed deployment never alters what Coroid believes is currently running in the environment. The Deploy step displays the failed attempt along with a link to your pipeline’s run. Fix the underlying issue, rerun any outdated checks, and deploy once more. Every attempt is recorded in the release’s history.

If an attempt appears to be stuck, check the run in your CI/CD and the reporting token before trying again. A missing report typically indicates a problem with the token or the event format, rather than a deployment failure.

When health requires attention

After a successful deployment, Coroid runs the project’s canary Quality Graph (a Quality Graph with a deployment_canary trigger) if one has been published. A failing canary displays Requires attention on the Health step. The deployment still counts as successful since the commit did reach the environment. Examine the canary’s evidence and your pipeline logs, then either proceed with a new release or revert to an earlier commit.

Revert to a stable commit

  1. 2.4.0 in ProductionDeployed, but the canary check failedNeeds attention
  2. Pick an earlier release that was healthy here
  3. 2.3.1Last healthy release in ProductionHealthy
Recovery deploys an earlier healthy commit through the same pipeline. Both deployments stay in history.

For the release currently deployed, open Health for the environment and locate Recover a previous stable commit. It lists earlier releases that were deployed there and passed their health check.

  • Your pipeline is linked to Coroid. Select Request rollback, specify a branch or tag that points to the stable commit, and provide a reason. Coroid verifies the ref and initiates a new run for the earlier release. The environment switches back only after the pipeline confirms success.
  • Your pipeline operates autonomously. Roll back there. If deployments are reported, Coroid automatically records the outcome. If reporting is unavailable, choose Record external rollback for the stable release. Coroid ensures the release being replaced remains the current one and that the target passed its health check.

Both the original deployment and the rollback remain visible in the history.

Ship multiple projects together

Some changes affect several projects, such as a new API and the app that relies on it. From the Releases list, select Coordinate a train, give it a name, and pick one release per project in the desired shipping order.

A train provides a shared view rather than a single deployment. Each release retains its own commit, checks, approvals, and pipeline, and you deploy each one from its respective page. The train displays Partially shipped while some releases have not yet reached their environments, keeping the remaining work visible.