Overview

The Release Process

In an sfp-powered project, releasing involves orchestrating the deployment of multiple artifacts (built packages) to target environments in a controlled, repeatable manner. The release process ensures consistency, traceability, and reliability across your Salesforce environments.

Key Components

Release Definition

A YAML file that specifies:

Which artifacts (packages and versions) to deploy
The release name and configuration
Deployment behavior (skip if installed, promotion settings)
Changelog generation settings

Release Commands

sfp provides several commands for managing releases:

Command	Purpose	Use Case
`sfp release`	Deploy a release candidate or definition to an org	Production deployments, environment updates
`sfp releasecandidate generate`	Create a release definition from a release config and publish it as a release candidate	Automated release preparation
`sfp repo:patch`	Apply release to a branch	Hotfixes, branch synchronization
`sfp changelog from-candidate`	Generate a release changelog from a candidate	Documentation, compliance

Release Workflow

1. Build and Publish Phase

After code is merged to your main branch:

# CI/CD builds artifacts
sfp build --branch main

# Publish to artifact registry
sfp publish --npm --scope mycompany

2. Release Definition Generation

Generate a release definition from the domain's release config and publish it to the server as a release candidate:

sfp releasecandidate generate \
  --gitref main \
  --configfile config/release-config-prod.yaml \
  --releasename "Release-2.0.0" \
  --branch main \
  --repository myorg/myrepo

See Generating a release definition for the full flag set, including --nopublish --output for writing the definition to a file.

3. Deployment Phase

Deploy the candidate generated in the previous step to your target environment:

sfp release \
  --releasecandidate core:Release-2.0.0 \
  --targetorg production \
  --repository myorg/myrepo

See Releasing to an environment for releasing several domains at once, promotion, dry runs and the full flag set.

4. Post-Release Activities

After a successful release:

# The release generates the changelog when passed --generatechangelog;
# generate one separately from a candidate with:
sfp changelog from-candidate \
  -n core:Release-2.0.0 \
  --repository myorg/myrepo \
  --output changelog

# Patch release back to development (if needed)
sfp repo:patch \
  --releasedefinitions releases/Release-2.0.0.yaml \
  --sourcebranchname develop \
  --targetbranchname feature/sync-prod-release

Release vs Install

sfp provides two deployment commands with different use cases:

sfp install

Installs artifacts from a local directory
Used for development and testing
Direct, simple deployment
Example:

sfp install --artifacts ./artifacts --targetusername myorg

sfp release

Fetches artifacts from a registry
Uses release definitions for consistency
Generates changelogs
Handles complex multi-artifact deployments
Example:

sfp release --releasecandidate core:Release-2.0.0 --targetorg prod --repository myorg/myrepo

Release Strategies

Progressive Deployment

Deploy through environments progressively:

# 1. Deploy to UAT
sfp release --releasecandidate core:Release-2.0.0 --targetorg uat --repository myorg/myrepo

# 2. Validate in UAT
# ... testing ...

# 3. Deploy to Production
sfp release --releasecandidate core:Release-2.0.0 --targetorg prod --repository myorg/myrepo

Hotfix Strategy

For urgent production fixes:

# 1. Patch production state to hotfix branch
sfp repo:patch \
  --releasedefinitions current-prod-release.yaml \
  --sourcebranchname main \
  --targetbranchname hotfix/urgent

# 2. Make fixes and build
sfp build --branch hotfix/urgent

# 3. Release hotfix
sfp release -p hotfix-release.yaml --targetorg prod

# 4. Sync hotfix back to develop
sfp repo:patch \
  --releasedefinitions hotfix-release.yaml \
  --sourcebranchname develop \
  --targetbranchname feature/hotfix-sync

Rollback Strategy

Prepare for potential rollbacks:

# Before release, save current state
mkdir -p rollbacks
sfp releasecandidate generate \
  --gitref main \
  --configfile config/release-config-prod.yaml \
  --releasename "rollback-snapshot" \
  --repository myorg/myrepo \
  --nopublish \
  --output rollbacks/rollback-snapshot.yaml

# If rollback needed
sfp release \
  -p rollbacks/rollback-snapshot.yaml \
  --targetorg prod

Domain-Based Release Configuration

sfp uses Release Configs to organize packages by domain. These configs define which packages belong to a domain and control various aspects of the release process:

# config/release-config-sales.yaml
releaseName: sales
pool: sales_pool
includeOnlyArtifacts:
  - src-sales-core
  - src-sales-ui
  - src-opportunity-management
  - src-lead-scoring
excludePackageDependencies:
  - Marketing Cloud
releasedefinitionProperties:
  changelog:
    workItemFilters:
      - SALES-[0-9]{3,4}
    workItemUrl: https://company.atlassian.net/browse
    limit: 30

# config/release-config-service.yaml
releaseName: service
pool: service_pool
includeOnlyArtifacts:
  - src-service-core
  - src-case-management
  - src-knowledge-base
  - src-service-console

Key points about release configs:

They define domains (logical groupings of packages), not environments
Packages must be explicitly listed in includeOnlyArtifacts
The same domain configuration is used across all environments (dev, uat, prod)
They control validation pools, changelog generation, and deployment behavior

The release definition generated from these configs determines which versions of packages are deployed to each environment.

On this page