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 artifacts to an org

Production deployments, environment updates

sfp releasedefinition:generate

Create release definition from artifacts

Automated release preparation

sfp repo:patch

Apply release to a branch

Hotfixes, branch synchronization

sfp changelog generate

Generate release changelog

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

Create a release definition for your target environment:

sfp releasedefinition:generate \
  --gitref main \
  --releaseconfig config/release-config-prod.yaml \
  --releasename "Release-2.0.0" \
  --directory releases

3. Deployment Phase

Deploy the release to your target environment:

sfp release \
  --path releases/Release-2.0.0.yaml \
  --targetusername production \
  --npm --scope mycompany

4. Post-Release Activities

After a successful release:

# Generate changelog
sfp changelog generate \
  --releasename "Release-2.0.0" \
  --directory 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 --path release.yaml --targetusername prod --npm

Release Strategies

Progressive Deployment

Deploy through environments progressively:

# 1. Deploy to UAT
sfp release --path release-uat.yaml --targetusername uat

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

# 3. Deploy to Production
sfp release --path release-prod.yaml --targetusername prod

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 --path hotfix-release.yaml --targetusername 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
sfp releasedefinition:generate \
  --gitref main \
  --releasename "rollback-snapshot" \
  --directory rollbacks

# If rollback needed
sfp release \
  --path rollbacks/rollback-snapshot.yaml \
  --targetusername 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.

Last updated