sfp - flxbl package manager
#flxblsfopsSlackGitHub
  • Overview
  • Getting Started
    • Pre-Requisites
    • Install sfp
    • Configure Your Project
    • Build & Install an Artifact
    • Congratulations!
    • Docker Images
      • sfp-pro
  • CONCEPTS
    • Overview
    • SF CLI vs. SFP
    • Domains
    • Packages
    • Supported package types
      • Unlocked Packages
      • Org-Dependent Unlocked Packages
      • Source Packages
      • Diff Package
      • Data Packages
    • Artifacts
    • Package vs Artifacts
    • Identifying types of a package
    • Dependency management
    • Transitive Dependency Resolution
    • Destructive Changes
  • configuring a project
    • Project structure
    • Setup Salesforce Org
    • Creating a package
    • Defining a domain
    • Release Config
  • BUILDING ARTIFACTS
    • Overview
    • Determining whether an artifact need to be built
    • Building a domain
    • Building an artifact for package individually
    • Limiting artifacts to be built
    • Controlling aspects of the build command
      • Ignoring packages from being built
      • Building a collection of packages together
      • Selective ignoring of components from being built
      • Use of multiple config file in build command
    • Configuring installation behaviour of a package
      • Always deploy a package
      • Skip Install on Certain Orgs
      • Optimized Installation
      • Pre/Post Deployment Script
      • Reconciling Profiles
      • PermissionSet Assignment
      • Updating Picklist
      • Entitlement Deployment Helper
      • Field History & Feed Tracking
      • Aliasfy Packages
        • Aliasfy Packages - Merge Mode
      • State management for Flows
  • Installing an artifact
    • Overview
    • Controlling Aspects of Installation
    • Applying attributes of an artifact
    • BuiltIn Deployment Helpers
      • PermissionSet Group Awaiter
  • publishing and fetching artifacts
    • Publish Artifact
    • Fetching Artifacts
  • Releasing artifacts
    • Overview
    • Release Definitions
    • Generating a release definition
    • Generating a changelog
  • Validating a change
    • Overview
    • Different types of validation
    • Limiting Validation by Domain
    • Controlling validation attributes of a package
      • Skip Testing
      • Skip Coverage Validation
      • Test Synchronously
  • Analysing a Project
    • Overview
    • Duplicate Check
  • Environment Management
    • Pools
      • Scratch Org Pools
        • Defining a pool
        • Setting up your Salesforce Org for Scratch Org Pools
        • Pool Operations
          • Preparing pools
            • Handling dependencies
          • List Scratch Orgs in a pool
          • Fetch a scratch org
          • Delete Pools
      • Sandbox Pools
        • Sandbox Pool Initialization
        • Fetch a Sandbox from Pool
        • Monitor Sandbox Pools
    • Review Environments
      • Commands
        • Fetch a Review Environment
        • Check Review Environment Status
        • Extend a Review Environment
        • Transition Review Environment Status
        • Unassign a Review Environment
      • Considerations
    • Sandbox
      • Create Sandbox
      • Delete Sandbox
      • List Sandbox
      • Login to Sandbox
      • Update Sandbox
  • Development
    • Development Environment
    • Pull Changes from your org
    • Push Changes to your org
    • Dependency Management
      • Expand Dependencies
      • Shrink Dependencies
      • Explain Dependencies
  • Running sfp as a server
    • Introduction
    • sfp-pro-server: Architecture Overview (Alpha)
      • Task Processing System
      • Authentication & Security Architecture
      • Authentication System: Deep Dive
      • Database Architecture
      • Network Architecture and Integration System
      • Integration Architecture: Building Extensions
    • Installing SFP Server
    • Initializing SFP server
  • Metrics
    • Available Metrics
    • Custom Metrics
    • Configuring Collectors
      • Datadog
      • Splunk
      • New Relic
      • StatsD
  • Helpers
    • Managing Shared Resources
  • Command Guide
    • Core
      • Build
      • Quickbuild
      • Publish
      • Install
      • Release
    • Advanced
      • Validate
      • Artifacts
      • Changelog
      • Impact
      • Pool
      • Metrics
      • Repo
    • Utilities
      • Apex Tests
      • Flow
      • Dependency
      • Profile
  • FAQs
    • Common Errors
      • Org Shapes
      • Troubleshooting Unlocked Packages Build Failure Due to Code Coverage
    • Common Questions
      • Email Templates Deployment: Classic vs Lightning
      • Dealing with Long Build Times in Salesforce
      • Standard ValueSets and unlocked packages
      • Common Issues encountered with aliasfied packages
      • API Version
      • Understanding alwaysDeploy and skipIfAlreadyInstalled in Deployment Pipelines
    • sfp versioning and upgrade Process
  • References
  • Legal
    • Terms of Service for sfp
    • Terms of Service for 'sfp-pro' Software
  • LLMs.txt
Powered by GitBook
On this page
  • Key Benefits
  • How It Works

Was this helpful?

Edit on GitHub
Export as PDF
  1. Environment Management

Review Environments

Review environments are a crucial component in the CI/CD workflow of flxbl projects. They provide isolated, ephemeral environments (either scratch orgs or sandboxes) for validating deployments, running tests, and performing acceptance testing during the pull request process.

Key Benefits

  1. Isolation: Each pull request gets its own environment, preventing conflicts between different features or bug fixes.

  2. Reproducibility: Environments are created from consistent pool configurations, ensuring predictable testing conditions.

  3. Early Validation: Catch deployment issues early in the development process.

  4. Automated Testing: Run tests against review environments to verify changes and prevent regressions.

  5. Collaboration: Provide a shared space for team members to perform acceptance testing and provide feedback.

  6. Compliance: Enforce governance policies and organizational standards before merging changes.

How It Works

  1. Environment Pools: Review environments are managed in pools, which can be either sandbox or scratch org pools.

  2. Fetching: When a pull request is opened or updated, a review environment is fetched from the appropriate pool. If an environment is already assigned to the issue, it may be reused if its lease hasn't expired.

  3. Usage: The environment is populated with the pull request changes and used for automated checks, manual testing, and review processes.

  4. Leasing: Environments are leased for specific durations to manage resource usage efficiently. While an environment is valid for 24 hours, it can be leased for shorter periods for specific processes.

  5. Status Management: Throughout its lifecycle, an environment's status can be transitioned between 'InUse', 'Available', and 'Expired' to reflect its current state and availability.

  6. Extension: If needed, an environment's overall validity can be extended beyond the initial 24-hour period.

  7. Unassignment: When no longer needed, environments are unassigned from issues and either returned to the pool or marked for deletion.

This lifecycle is managed through a set of sfp reviewenv commands, which automate the process of fetching, checking, transitioning, extending, and unassigning review environments.

PreviousMonitor Sandbox PoolsNextCommands

Last updated 8 months ago

Was this helpful?