> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/sfp/releasing-artifacts/overview.md). # 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`](/flxbl/sfp/releasing-artifacts/releasing-to-an-environment.md) | 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 ```mermaid graph TD A[Build Artifacts] --> B[Publish to Registry] B --> C[Generate Release Definition] C --> D[Deploy with sfp release] D --> E[Generate Changelog] D --> F[Patch to Branches if needed] F --> G[Continue Development] ``` ### 1. Build and Publish Phase After code is merged to your main branch: ```bash # 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: ```bash 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](/flxbl/sfp/releasing-artifacts/generating-a-release-definition.md) 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: ```bash sfp release \ --releasecandidate core:Release-2.0.0 \ --targetorg production \ --repository myorg/myrepo ``` See [Releasing to an environment](/flxbl/sfp/releasing-artifacts/releasing-to-an-environment.md) for releasing several domains at once, promotion, dry runs and the full flag set. ### 4. Post-Release Activities After a successful release: ```bash # 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: ```bash 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: ```bash sfp release --releasecandidate core:Release-2.0.0 --targetorg prod --repository myorg/myrepo ``` ## Release Strategies ### Progressive Deployment Deploy through environments progressively: ```bash # 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: ```bash # 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: ```bash # 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](/flxbl/sfp/development/defining-a-domain/release-config.md) to organize packages by domain. These configs define which packages belong to a domain and control various aspects of the release process: ```yaml # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.flxbl.io/flxbl/sfp/releasing-artifacts/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.