Releases

The factory turns tasks and plans into reviewed pull requests. Once they are merged, a release answers the next question: which of that work is running where, and was it safe to put there?

A release pins one exact Git commit and follows it through your environments, for example Staging and then Production. The commit can already be on your deployment branch, or Coroid can first bundle open pull requests into one release pull request whose merge commit becomes the release. At each stop, Coroid checks the commit, collects the approvals you ask for, and records the deployment your CI/CD reports back. Coroid never marks a release deployed on its own word. Your pipeline, or a person recording an external deployment, has to confirm it.

The idea in one minute#

• Release: one commit, a name, and an optional version. A version such as 2.4.0 is optional, so continuous delivery works without tags.
• Environment: a stop on the way to your users, such as Staging or Production. Each project defines its own stops and their order.
• Rollout: which environments the release has reached so far.
• Work: the tasks planned for the release and the merged changes it contains, shown as done out of total.
• Four steps per environment: checks, approval, deploy, and health. The release page always opens the step that needs you.
• Bundle: a release built from open pull requests. Coroid merges them into one release branch, in an order you can change, and opens one release pull request. A bundle release has a fifth step, Bundle, before checks.

Read a release at a glance#

Open Releases in the main sidebar for every project, or a project's Releases tab for just that project. Running now, at the top, shows the version each environment runs, from its last confirmed deployment, whoever started it. The list shows each release's work progress, its rollout across environments, and its status. Use the tabs to switch between releases that are in progress, shipped, or closed.

Select a release to open its page.

The rollout track is also a switch. Select an environment on it to see that environment's four steps. The page opens on the first environment the release has not reached yet, so the next thing to do is usually already in view.

The four steps at every environment#

Checks. Choose Run checks. Coroid runs the project's release validation Quality Graph against the exact commit and confirms that every linked change is inside that commit. Any required checklist items for the environment must also be marked complete. If something blocks the release, the step lists what it is. Changing the commit or the linked changes makes earlier checks out of date, and the step asks you to run them again.

Approval. Once checks pass, the people your rules allow can approve. The step shows how many approvals are needed and from which roles. If your rules require approved release notes, the notes are approved here too.

Deploy. When checks and approval are complete, the release is ready for the environment. If Coroid is connected to GitHub Actions or GitLab CI/CD for that environment, an Owner or Admin chooses Deploy to… and Coroid starts the pipeline for that exact commit. Otherwise your pipeline deploys on its own and reports back. Either way, the step only turns green when a success is confirmed.

Health. After a successful deployment, Coroid runs the project's canary Quality Graph if you have one. A passing canary marks the environment healthy. A failing one shows Needs attention and offers recovery. Without a canary, health stays unknown rather than healthy by assumption.

What the statuses mean#

Ready never means deployed. Only a confirmed deployment moves a release forward on the rollout track.

Workflows#

Set up releases for a project#

Do this once per project. Open Releases, choose Release settings, and pick the project.

1. In Environments, add your stops and put them in order, for example Staging before Production.

2. In Approval rules, publish rules for each environment: how many approvals, from which roles, and any checklist items. An environment cannot pass its checks until rules are published.

3. In Deploy pipeline, choose whether Coroid starts deployments or your pipeline does. Then create a reporting token so your CI/CD can tell Coroid what it deployed.

4. In Versioning, choose where each release's version comes from, and give each environment a version URL so Coroid can confirm what runs there.

Release settings walks through each screen, and Put the version in your build shows how the version reaches your app.

Ship planned work#

Use this when you know ahead of time what should go out together.

1. Create the release early, before a commit is pinned. It starts as a draft.
2. Set the target release on the tasks you want in it. They appear under Planned tasks, and the work bar fills as they finish.
3. When the work is merged, choose Edit details and pick the commit to ship. Coroid confirms which merged changes the commit contains.
4. Go through the four steps for your first environment, then the next.

Bundle open pull requests#

Use this when many pull requests are waiting, from Coroid or from your team, and they should ship together.

1. Choose New release, pick the project, and choose Open pull requests. The option needs a GitHub or GitLab repository, so Coroid-hosted projects release a commit instead.
2. Coroid lists the open pull requests into the deployment branch, safest first. A pull request that Coroid opened shows as its task or plan. Coroid weighs what the provider and its own review already know: checks, reviews, size, conflicts, and files that several pull requests touch. It leaves out drafts, failing checks, requested changes and pull requests from forks, and says why.
3. Untick what should wait, and use the arrows to change the order. A pull request that builds on another one (a stacked pull request, or one that says "depends on #12") always comes after it.
4. Choose Create release. Coroid creates release/<version> from the deployment branch, merges the pull requests in order, and opens one release pull request that lists and links each of them.
5. If a pull request conflicts with the release branch, the Bundle step stops there and shows the files. Choose Resolve with Coroid to let the developer agent merge it and resolve the conflict in a task, or Leave it out to continue without it.
6. Review the release pull request and merge it with a merge commit. Your provider then marks every bundled pull request as merged. Coroid pins the merge commit as the release commit, records the bundled pull requests as what ships, and closes any that are still open with a link to the release pull request.
7. Go through the four steps for each environment as usual.

Squash or rebase merges also work, but the original pull requests are not marked merged by your provider. Coroid closes them with a comment instead.

Ship what is on the main branch#

Use this for continuous delivery, when you ship whatever has merged.

1. Choose New release and pick the commit, usually the latest on the deployment branch.
2. Under Compare with, pick the environment you are about to replace. Coroid lists the pull requests and commits between what runs there and your commit, and selects the ones it can verify.
3. Leave the name and version empty if you like. Coroid names the release from the date and the short commit, and the project's version source fills in the version. Every release also gets the next build number.
4. Create the release and follow the four steps.

If your pipeline deploys on every merge, or someone deploys by hand, without asking Coroid, it can still report each deployment. When no release exists for a reported commit, Coroid creates an observed release for it, clearly marked as not having passed Coroid's checks. It gets the version the pipeline reported, or, when Coroid assigns the project's versions, the next one (1.4.1 after 1.4.0), and the next build number.

Ship an urgent fix#

An Owner or Admin can turn on This is a hotfix when creating a release, pin the fix's full commit, and say why normal timing does not work. Hotfixes follow each environment's hotfix rules, which can require fewer approvals. Quality checks and required checklist items still apply, and only Owners and Admins approve hotfixes.

Recover when something breaks#

If the health step shows Needs attention, open Health on the affected environment and pick an earlier healthy commit to redeploy. Recovery and release trains covers the options, including pipelines that cannot report back.

From chat or your editor#

The chat assistant and Coroid's MCP server have the same release tools: list and inspect releases, pick a commit, preview what would ship, prepare a release, bundle open pull requests, run its checks, approve it, ask for a deployment and draft notes. Bundling, approving and deploying always need a person to confirm. See Chat assistant and Coroid as an MCP server.

Release several projects together#

A release train groups releases from several projects that must ship together, in order, such as an API and the app that depends on it. See Recovery and release trains.

What Coroid does and does not do#

• Coroid pins, checks, and records. Your repository and CI/CD build and deploy.
• When it bundles pull requests, Coroid creates the release branch and the release pull request. It never merges the release pull request for you.
• Coroid starts a pipeline only when you connect one and an Owner or Admin asks for a deployment.
• A deployment request is not proof. The rollout track moves only when your pipeline confirms success or someone records a verified external deployment.
• Release notes are drafts you edit and approve. Coroid does not publish them anywhere.
• A sprint is a planning period, not a deployment boundary. One sprint can feed several releases, and one release can hold work from several sprints.

Related#

• Release settings
• Deployment events and CI setup
• Put the version in your build
• Recovery and release trains
• Sprints
• Tasks, plans, sprints and lanes
• Quality and review evidence