flxbl docs
slackGitHub
  • flxbl
  • sfp
  • sfops
  • Introduction
  • Minimal Framework
  • Who uses flxbl?
  • Learnings from the flxbl community
  • OVERVIEW
    • Principles
    • Modular Development Renaissance for Salesforce
    • Toolbox
  • TECHNIQUES
    • Development Practices
      • Why modular development in Salesforce?
      • Organizing your code / config
      • Defining the boundaries of a package
    • Source Code Management
      • Project Structure
      • Branching Model
      • Branching Conventions
      • Feature Toggling
      • Dealing with Org Specific Metadata
      • Handling Profiles
      • Tracking Manual Steps
    • Environment Management
      • Guiding Principles
      • Pooling Scratch Orgs
  • BUILD AUTOMATION
    • sfp
  • CI/CD
    • sfops
  • Libraries
    • sfdc-feature-management
    • sfdc-trigger-framework
    • nebula logger
  • tools
    • sfdmu
    • browserforce
    • pmd
Powered by GitBook
On this page
  1. TECHNIQUES
  2. Environment Management

Guiding Principles

Last updated 2 months ago

Environment Management in flxbl project follow guidelines as laid out by the guide, Rehashing some of the most important principles here

  • Release stages apply to release artifacts, not environments.

  • Every development environment should be refreshed or destroyed as soon as the relevant work is finished (within limits).

  • Environments are only as useful as the kind of production fidelity they do (and do not) provide. Optimize your environment setup workflows or automations to allow for environment teardown/refresh at the earliest possible interval.

In order to cater the above requirements, flxbl projects work with the concept of environment categories, any number of sandboxes can be added to any of these categories. These environment categories form the deployment target in your pipelines.

In addition to the above categories, flxbl project utilize three categories of development environments

Salesforce Well Architected
Test Environments
Development Environments