CoroidYour AI software factory
Documentation

Recovery and release trains

Respond to a failed deployment or health check, go back to a healthy commit, and ship releases from several projects together.

When a deployment fails

A failed deployment never changes what Coroid thinks is running in the environment. The Deploy step shows the failed attempt with a link to your pipeline's run. Fix the cause, run the checks again if they went out of date, and deploy again. Every attempt stays in the release's history.

If an attempt seems to hang, check the run in your CI/CD and the reporting token before retrying. A missing report usually means the token or the event format needs attention, not that the deployment failed.

When health needs attention

After a successful deployment, Coroid runs the project's canary Quality Graph (a Quality Graph with a deployment_canary trigger) if one is published. A failing canary shows Needs attention on the Health step. The deployment still counts as successful, because the commit really reached the environment. Look at the canary's evidence and your pipeline's logs, then either fix forward with a new release or go back to an earlier commit.

Go back to a healthy 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.

On the release that is currently deployed, open Health for the environment and find Recover a previous healthy commit. It lists earlier releases that deployed there and passed their health check.

  • Your pipeline is connected to Coroid. Choose Request rollback, enter a branch or tag that points at the healthy commit, and say why. Coroid checks the ref and starts a new run for the earlier release. The environment switches back only when the pipeline confirms success.
  • Your pipeline runs on its own. Roll back there. If it reports deployments, Coroid records the result automatically. If it cannot report, choose Record external rollback on the healthy release. Coroid checks that the release you are replacing is still the current one and that the target passed its health check.

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

Ship several projects together

Some changes span projects, for example a new API and the app that uses it. From the Releases list, choose Coordinate a train, name it, and pick one release per project in the order they should ship.

A train is a shared view, not a single deployment. Each release keeps its own commit, checks, approvals, and pipeline, and you deploy each one from its own page. The train shows Partially shipped while some members have not reached their environments yet, so the remaining work stays visible.