Concepts

The Release Candidates page showing domains, candidates, and action buttons

This page explains what you are looking at and how release candidates appear in codev. It is written for product owners and release managers who need to read the UI with confidence.

Release config

A release config is a YAML file in your repository that defines which packages belong to a release domain. It acts as the blueprint for what gets released together.

config/release-config.yaml

releaseName: my-domain
pool: main-pool
excludeAllPackagesInRepoByDefault: true
includeOnlyArtifacts:
  - core-model
  - core-triggers
  - reporting-dashboards

A single repository can have multiple release configs, each representing a different domain.

Reference: Configuring a Release Definition

Release definition

A release definition is a snapshot of specific package versions at a point in time. It is generated from a release config by the pipeline and records exactly which artifact versions should be deployed together.

release: my-domain
metadata:
  commit_sha: abc123def
  branch: main
  repository: myorg/myrepo
artifacts:
  core-model: 1.5.0
  core-triggers: 1.5.0
  reporting-dashboards: 2.1.3

The release definition answers: "For this domain, which exact versions were built from this commit?"

Reference: Generating a Release Definition

Release candidate

A release candidate (RC) is the deployable unit that appears in the codev UI. It represents packages that have already been built, tested, and published by the pipeline.

Each RC belongs to a domain and has a status:

Status	Meaning
active	Available for promotion to environments
released	Deployed to one or more environments
superseded	A newer RC for the same domain has been created

A release config is a template. A release definition is a snapshot. A release candidate is the deployable snapshot you act on in codev.

How release candidates appear in codev

codev does not create release candidates. It displays what your CI/CD pipeline produced. The pipeline is fully automated — every merge to your trunk branch triggers it.

The trigger

A developer merges a pull request into main (or your configured trunk branch). This is the only action required. Everything else is automated.

What happens automatically

1. Your CI/CD pipeline detects the merge and starts a build.

2. The pipeline identifies which packages changed and which domains are impacted.

3. Only the impacted packages are built, tested against target environments, and published as artifacts.

4. After a successful publish, the pipeline generates a release definition and sends it to sfp server.

5. sfp server stores the release candidate. codev displays it on the Release Candidates page within seconds.

Only impacted domains receive a new release candidate per merge. If your PR changed packages in the sales domain only, the frameworks domain does not get a new RC.

Prerequisites

All of the following must be in place before release candidates appear in codev.

Prerequisite	Where to configure	Reference
A release config YAML in your repository	config/release-config.yaml (or your configured path)	Release Config
A CI/CD pipeline that builds and publishes on merge	Your CI/CD platform (GitHub Actions, etc.)	Pipeline setup
sfp server running and accessible from the pipeline	Server URL and authentication configured as pipeline secrets	sfp server
A project selected in codev that matches the repository	Footer bar in codev (bottom-left project selector)	—
At least one successful merge to trunk	The first merge triggers the first build and RC	—

Not seeing release candidates?

Symptom	Check
RC page is completely empty	Verify the correct project is selected in the footer bar. The project must match the repository where your pipeline runs.
RCs appear for some domains but not others	Only domains with changed packages get new RCs. Check if your PR actually modified packages in the missing domain.
Build succeeded but no RC appeared	Open CI/CD > Builds in codev. If the build shows "Done" but no RC name, the release definition generation step may have failed. Check the pipeline logs.
"No environments configured" in Release dialog	Environments are not yet registered in sfp server. See Environment Management.
codev shows "Offline" in dashboard	sfp server is not reachable. Check the server URL in Settings > General and verify the server is running.

What the Release Candidates page shows

The screenshot above contains real example data. Use it to map the UI elements to the descriptions below.

Stats bar

Metric	Example value	What it tells you
DOMAINS	2 with candidates	How many domains currently have RCs
CANDIDATES	7 ready to deploy	Total RCs across domains
WORK ITEMS	6 pending release	Open work items linked to RCs
OLDEST	176d unpackaged	Oldest RC age and its domain

Filters and navigation

Control	Example values	Purpose
Domain filters	frameworks, sales, unpackaged	Show RCs for one or more domains
Age filters	<3d, 3-7d, >7d	Focus on fresh vs. aging RCs
Branch tabs	main (3), patch branches	Switch between trunk and patch RCs
Search	Text search	Find RCs by name, package, or work item

Table columns

Column	What you see
NAME	Release candidate name and domain
DATE	When the RC was created
WORK ITEMS	Linked issues/work items
CUMULATIVE	All packages included in the RC
LINKED WITH	Related releases (cross-domain)
ARTIFACTS	Package versions in the RC
DEPLOYED TO	Environments where this RC is already deployed
ACTIONS	Release, Get on Sandbox, Patch