Managing Release Candidates

Once you have release candidates on the Release Candidates page, you can deploy them, test them, or use them as the basis for a hotfix. This page walks through each action.

Release

Requesting a release for a selected candidate

Use Release when you want to deploy a candidate to an environment — typically staging, UAT, or production.

How it works

1. Click Release on the release candidate you want to promote.

2. The dialog shows you the release definition (domain and release name) and a list of indicative work items that will be included.

3. Work items are color-coded:

   • Green — this release will fully deploy the work item

   • Orange — only a partial deployment (other domains still need releasing for the work item to be complete)

   • Grey — the work item is linked to a release candidate in a different domain

4. If the release candidate has linked RCs in other domains, you can select or deselect them.

5. Confirm the target environment and click Request Release.

What happens after you click Request Release

codev kicks off the release workflow:

1. A dry run validates the release — confirming which packages will be deployed and checking compatibility with the target environment.

2. The request enters an approval gate. Designated approvers on your team receive a notification and can review, approve, or reject from Workflows > Pending Approvals.

3. Once approved, codev locks the target environment, deploys the packages, and unlocks it.

4. The release appears on the Releases page.

If your release candidate has multiple target environments, each environment gets its own approval gate and deploys independently. The whole process is tracked in Workflows > Runs.

The approval gate ensures that nobody deploys to production without review. If your team wants to skip approval for certain environments (like a dev sandbox), that can be configured in your workflow settings.

Get on Sandbox

Deploying a release candidate to a sandbox for testing

Use Get on Sandbox when you want to test a release candidate before formally releasing it. This deploys directly — no approval gate, no waiting.

How it works

1. Click the sandbox deploy action on the release candidate row.

2. Choose one or more target sandbox environments.

3. Select an environment profile (default: DEV).

4. Optionally enable Force Install to reinstall packages even if they are already present in the target org.

5. Click Deploy to Sandbox.

The deployment starts immediately and you can track it in Workflows > Runs.

Patch

Creating a patch branch from a release candidate

Use Patch when you need a hotfix. This creates a new branch from the exact state of a release candidate, so you can fix a production issue without picking up all the other changes that have been merged since.

How it works

1. Click the patch action on the release candidate row.

2. Confirm the source branch (default: main).

3. Click Create Patch Branch.

codev creates a new branch in your repository. It appears as a separate tab on the Release Candidates page. Developers push their fix to this branch, and when the fix is merged, codev builds a new release candidate scoped to the patch — which can then be released through the normal flow.

Release candidate lifecycle

Release candidates move through these statuses as your team works with them:

• Active — ready to be released or tested

• Released — deployed to at least one environment

• Superseded — a newer release candidate exists for the same domain (this one is still deployable if needed)

You can still release a superseded RC. The status is informational — it tells you a newer version is available, but it does not block you from deploying an older one if needed.

Related

• Release Candidates: Concepts and page overview

• Builds: How packages are built

• Releases: What is deployed where