Describe the environments, requirements, and process for deploying code and associated configurations.

After studying this topic, you should be able to:

  • Describe the different sandbox environments and their roles in the application development lifecycle
  • Determine the requirements, considerations, and processes involved in development and deployment
  • Identify the different types of development models for building applications in Salesforce
  • Identify the different tools that can be used for deploying metadata from one org to another

Table of Contents

  • Introduction
  • Sandboxes
  • Development Models
  • Change Set Development Model
  • Org Development Model
  • Package Development Model
  • Development Requirements
  • Deployment Tools
  • Change Sets
  • Deployment Settings 1 2 3
  • Change Sets Used for Migrating Changes 1 2 3
  • Visual Studio Code
  • Ant Migration Tool
  • Metadata and Tooling API
  • Unmanaged Packages
  • Managed Packages
  • Workbench
  • Performance Assistant

Introduction

  • Section describbes the role of different development and deployment environments for projects that involve development of Salesforce applications and deployment tools that can be used
  • Different environments are used for various purposes, such as:
    • Development: used for customization and application development
    • Integration
    • Testing: used for integration and user acceptance testing
    • Staging: used for test deployment before migrating changes to production
    • Training
  • Sandbox environments are typically used to develop and test new functionality before migrating it to production using a development tool
  • Different types of sandbox orgs and their use cases are also described
  • Other tools that can be used like VS Code, Ant Migration Tool, etc, are also covered

  1. Development Environment: Developers use Salesforce web and local tools to customize Salesforce and develop applications
  2. Integration Environment: Changes from development environments are migrated to integration environment for testing
  3. UAT Environment: Changes from integration environment are migrated to UAT environment for user acceptance tests
  4. Staging Environment: Changes from UAT are migrated to staging environment and production changes are replicated
  5. Production Environment: The release is scheduled, and changes are finally migrated to Production from Staging environment
  • Salesforce Org Types: Typical Salesforce environment consists of two types, a single production org and one or more sandbox orgs:
    • Production org: live instance or production environment where real data and users of an organization exist
    • Sandbox Org: A nearly identical copy of the production org and is used for development and testing
    • Scratch Org: A source-driven short-lived org used to emulate a specific org for development and automation
    • Developer Org: A Developer Edition org, which is a free copy of the Enterprise Edition org but with less storage and users
    • Trial Production Org: A trial org that includes sample data and edition-based features for evaluating the Salesforce platform
    • Partner Developer Org: A licensed version of the Developer Edition org and includes more storage, licenses, and features

Sandboxes

  • A sandbox is a copy or a related production org or another sandbox to allow development and testing without affecting metadata or data in the source org
    • Metadata/Data Copy: when created, sandboxes copy metadata (configuration) only, but some can contain data (records) too
    • Development and Testing: Sandboxes are used to develop and test in a safe environment, completely separate from production
    • Develop/Test in Sandbox: Although it is very easy to make changes to configuration directly in production, it’s best practice to develop and test
    • Four types of sandboxes:
      • Developer: A Developer sandbox includes the production org’s metadata, has a file and storage limit of 200 MB, and can be refreshed once every day
      • Developer Pro: The Developer Pro sandbox includes the production org’s metadata, has a file and storage limit of 1 GB, and can be refreshed once every day
        • Can be used to handle more development and quality assurance tasks, and for integration testing and user training
      • Partial Copy: A Partial Copy sandbox uses a template to define the data, has a file and storage limit of 5 GB, and can be refreshed every 5 days
        • Partial Sandboxes require use of a sandbox template, which select specific objects and data to copy to a sandbox to control size and content
        • Template limit of max 10,000 records per object can be copied
        • Partial sandbox is attractive as it is cheaper than a full copy and can be refreshed much more frequently
      • Full Copy: A Full Copy sandbox is a copy of the entire production org, including data, has the same data and storage limits, and can be refreshed every 29 days
        • Optional Template: can be used if preferred
        • Generally used for UAT (User Acceptance Testing) or performance testing for new or changed functionality before its moved to production, or for debugging issues that occurred in the production org

  • Using a Sandbox: types of sandboxes available depend on the org edition, and a sandbox can be used for each particular stage in the lifecycle of an application
    • Editions and Sandboxes: number of sandboxes that can be created and the types available depend on the org edition. Some are standard, and some are available for an extra cost, e.g., Enterprise edition does not include a full copy sandbox, but Performance and Unlimited edition do
    • Sandbox Environments: production orgs can have one or more sandboxes associated. Most larger organizations have at least 3: development environment, test environment, and production
    • Systemize Workflow: Changes can be developed in development, tested in test, and then moved to production using change sets
    • Sandboxes can be used to evaluate apps from the AppExchange
    • Sandbox Email Addresses: When new sandboxes are created or refreshed, Salesforce appends “.invalid” to all email addresses
    • Match User Licenses: sandboxes provision the same number of licenses that are in production when generated. If more are added, they can be updated via match production licenses option in Company Information in setup
  • Sandbox Cloning: sandbox environments can be cloned instead of using the production org as the source
    • Easy customization: cloning an existing sandbox can simplify the customization of a new sandbox environment
    • Data and Metadata: cloning copies both
    • Manage Work Streams: can be utilized to manage multiple concurrent work streams in the application lifecycle
    • Create From: when creating a new sandbox, an existing org can be cloned by seleccting a sandbox from the Create From dropdown
    • Tooling API: can be used to clone a sandbox, in addition to the web interface

Development Models

  • High-level, there are three development models of building or customizing applications in Salesforce. Each has their own deployment processes
    1. Change Set Development Model
    2. Org Development Model
    3. Package Development Model

  • Tools used in the process vary, but the high-level steps in the Application Lifecycle Management cycle applies to any Salesforce development model that is being used
    1. Plan Release: Identify and analyze requirements, build estimates, and plan development implementation
    2. Develop: Build and complete project based on design specifications in a development environment using declarative/programmatic tools
    3. Test: Test the changes or customizations made to ensure that they work as expected in the development environment
    4. Build Release: Collect and bundle the modified metadata and additional assets that are needed in the release to ready for production
    5. Test Release: Test release in a staging org with sample production data, perform integration, full regression and performance tests
    6. Release: Deploy the customization to production after successful testing. Educate users, and build a training environment if needed

Change Set Development Model

  • Change Set Development model is a declarative method of developing and deploying metadata changes using Change Sets. Consists of the following steps:
    1. Exclusive Sandboxes: A separate Developer sandbox is created for each developer to ensure that the changes remain isolated until the team is ready to integrate them
    2. Develop and Test: The developers use their Developer sandboxes to create and test customizations based on business requirements. The sandboxes do not contain production data
    3. Develop for Integration: Change Sets are used to migrate customizations from the Developer sandboxes to a shared Developer Pro sandbox for integration
    4. Develop for UAT: Change Sets are used to migrate customizations to a full sandbox which is used for user acceptance testing. The full sandbox contains all the production data
    5. Deploy for Production: The customizations are migrated to the production environment using Change Sets. The full sandbox can be used for end-user training

  • Considerations for using the Change Set Development Model
    • Tracking Changes: A change-tracking method needs to be established for tracking changes, especially for changes that require manual migration
    • Use Tracking Tools: A custom or third-party tool can be utilized by developers to log each change made by them
    • Manual Configuration: Configurations involving metadata that are not supported by the Metadata API requires recreating the customization manually in the destination org
    • Metadata Converge Report: The Metadata Coverage report shows which metadata types are supported in the Metadata API and other metadata channels

Org Development Model

  • Org Development model involves working with orgs that don’t have source tracking, or retrieving and deploying code directly to a target org
  • Considerations for using the Org Development Model
    • Salesforce DX Project: A Salesforce DX project is created to contain source code and metadata files
    • Multiple Environments: Multiple environments are set up to handle the different phases of the application development lifecycle
    • Salesforce CLI: Salesforce CLI is used in each phase of the application development lifecycle such as retrieving source files from the org or deploying changes to the target org
    • Manual Tracking: Tracking changes is done manually using change list which contains a simple list, table, or spreadsheet of changes made in an org that need to be migrated
  • Phases of the Org Development Model follow:
    1. Develop and Test: Changes are made in a separate development environment such as a Developer sandbox with no production data
    2. Build Release: Changes are deployed to a shared development environment for integration testing
    3. Test Release: Changes are deployed to a sandbox environment for user acceptance testing
    4. Deploy Release: Changes are deployed to a production environment

Package Development Model

  • Package development model involves creating a package of customizations that is deployed to the production environment
    • Release Artifact: A package is a release artifact that contains a group of related code and customizations
    • Package Contents: Source code and metadata are organized into a package
    • Code Versioning: Versioning is used to facilitate change management. A Version Control System plays an integral role in the package development lifecycle
    • Code Repository: A source control repository is used to store the source code for the packages and maintain the source of truth
    • Scratch Orgs: Scratch (development) orgs are from the source in the repository to work specifically on the package
    • Salesforce DX Project: Salesforce DX is used to test, build and release packages. A Salesforce DX project is used to organize the source into a package directory
    • Process Automation: Automated testing, continuous integration, and continuous delivery are typically utilized in the package development lifecycle. Salesforce CLI can be used throughout the lifecycle
    • Unlocked Packages: Enterprise edition customers can utilize unlocked packages to develop internal business apps
  • Sample Execution Flow in a Package Development Model: Activities related to source development are performed in scratch orgs, whereas release and deployment testing activities are performed in sandbox orgs

Development Requirements

  • Requirements and considerations to know before deploying Apex code to a production org:
    • Code Coverage Requirement: At least 75% of Apex code must be covered by unit tests
    • Coverage Best Practice: Although 75% code coverage is the minimum code coverage for deploying code to production, test coverage should be as high as possible, and testing should cover every use case of the application
    • Successful Compilation: All classes and triggers must compile successfully
    • Code Coverage Exclusion: Test methods and test classes are not counted as part of code coverage
    • Covered vs Total Lines: Code coverage depends on the total number of code lines in the organization
    • Average Coverage: When deploying new components that have 100% coverage to production, the deployment will fail if the average coverage of the new and existing code does not meet the 75% threshold
    • Optimize Unit Tests: If a test run in the destination organization returns a coverage result of less than 75%, the existing test methods need to be modified or additional test methods written to raise the code coverage over 75%
    • Processes and Flows: Active processes and autolaunched flows are deployed as inactive by default. To deploy a process or autolaunched flow as active, the org must meet flow test coverage requirements, which is independent from the required Apex code coverage and defined separately in Setup.
    • Deploy Optimized Tests: The optimized or new test methods can be deployed separately or together with new code that has 100% coverage
    • Data Dependency: Test coverage results can differ when tests use the @isTest(SeeAllData=true) annotation, depending on the availability of data
    • Sync Metadata Changes: Changes to metadata, such as profile settings, should match in the sandbox and production before deployment
    • Managed Package Code: Unlike overall code coverage calculation in Developer Console, an organization’s code coverage computed in a deployment can cover managed package code through the RunAllTestsInOrg test level
    • Deployment Connection: When using change sets, a deployment connection is required between two Salesforce orgs to send change sets from one org to another
    • Tests in Production: For deployment to a production org, all local tests in the org are run by default. No tests are executed if no test level is specified, unless the deployment package contains Apex classes or triggers. Tests that originate from installed managed packages aren’t run by default. If any test fails, the entire deployment is rolled back
    • Testing Framework: The testing framework provides a robust framework to create unit tests, run unit tests, run only the code that is marked as tests, check the test results and code coverage to ensure that the code can be deployed to production
  • Deployment Considerations
    • When metadata is deployed, user references such as the users that email notifications, workflow rules, etc, should be associated with are matched
    • Metadata Files: Customizations and code are retrieved or deployed using the Metadata API as XML files, which also includes the version of the Apex runtime engine
    • Unsupported Metadata: The Metadata API does not support all metadata types. Unsupported metadata cannot be deployed from one org to another and needs to recreated manually
    • Metadata Overwrite: Deployed metadata is not merged with existing metadata in the org, but overwrites it. Also, a renamed metadata component will be received as a new component

Deployment Tools

  • Metadata Deployment: different tools that can be used for deploying metadata to a Salesforce org:
    • Ant Migration Tool: This command-line tool can be used to move metadata between related or unrelated environments
    • Visual Studio Code: Salesforce Extensions for VS Code provide tools for development and deployment between orgs
    • Managed/Unmanaged Packages: Managed or unmanaged packages can be used to distribute a bundle of components across Salesforce orgs
    • Workbench: Workbench can be used to retrieve or deploy components using a package.xml file used to list the components
    • Metadata API: Metadata API can be used to retrieve, deploy, create, update, or delete customizations from any org
    • Tooling API: Tooling API allows fine-grained access to an org’s metadata and can be used for integrating it with other systems
    • Change Set: Change sets can be used to deploy metadata changes from one org to a related production org or another sandbox org

Change Sets

  • Change sets can be used to deploy metadata from one org to a related production or sandbox org
    • Deployment Connection: A deployment connection is required to deploy metadata using a change set; the destination org must also authorize it
      • When a Sandbox is created from a Production org, a deployment connection is automatically set up between the two orgs
    • Inbound and Outbound Change Sets: An outbound change set is created in the source org and inbound change set is received in the **destination org
    • Validation and Deployment: It is possible to validate an inbound change set before deployment to make sure that there’s no error during actual deployment
    • Considerations: Change sets cannot delete or rename components
    • Test Options: Test options available for deployment are ‘Default’, ‘Run Local Tests’, ‘Run All Tests’, and ‘Run Specified Tests’
    • Creating a Change Set: A change set is created by adding metadata components and any dependent components which get migrated together.
    • Supporting Editions: Change sets are available in Enterprise, Performance, Unlimited and Database.com editions
    • Change sets deploy metadata, not data
  • Following shows the steps involved when deploying a change set from a source to a destination org

  • Example deployment settings page shown below. One sandbox is not configured to send or receive metadata
    • Each deployment connection in the Deployment Setting screen can be edited to select the Allow Inbound Changes option, which means orgs are allowed to push changes to the current org

  • On deploy of inbound change sets, the available test options are:
    • Default: No tests are run for sandboxes, and all local tests are run for production deployments
    • Run Local Tests: All tests except those from installed managed packages are executed
    • Run All Tests: All tests including those from installed managed packages are executed
    • Run Specified Tests: Only the specified test classes are executed; the executed tests must cover the class or trigger in change set with a minimum of 75% code coverage
  • More considerations when using change sets:
    • Include Dependencies: All dependent components should be added as part of a change set to avoid unexpected errors
    • Rollback on Failure: If a deployment is unable to complete for some reason, the entire transaction is rolled back
    • Permissions Sets vs Profiles: Permission sets are added as a component in the change set, whereas a Profile is added in the Profile Settings for Included Components section
    • Provide Buffer Time: Sufficient buffer time ought to be kept in a deployment schedule in order to accommodate for unforeseen delays due to server load
    • Deployment Order: A change set can identify dependencies and bundle altogether the components that need to be deployed, but it cannot control the order in which the individual components will be deployed in the destination org
    • Split Change Sets: If there is a component that needs to be deployed before another, two separate change sets might need to be created, uploaded, and deployed accordingly
    • Deploy All or None: Partial deployment is not possible using change sets. Either all components are deployed, or none of them gets deployed

Visual Studio Code

  • Retrieve Source Code: Code can be retrieved from any authorized org by selecting SFDX: Retrieve Source from Org (force:source:retrieve) or force:mdapi:retrieve
  • Deploy Source Code: Code can be deployed to any authorized org by selecting SFDX: Deploy Source to Org (force:source:deploy) or force:mdapi:deploy
  • Metadata can be deployed in VS Code by:
    1. using the menu option
    2. selecting an action in the command palette
    3. entering the command directly in the integrated command line terminal

  • Changes between a local project and a sandbox org caan be tracked by running the sfdx force:source:status command. To use this feature, source tracking must be enabled in the org

  • Salesforce Functions allows using common industry languages to write code that is managed by the Salesforce platform and can be invoked using Apex
    • DevHub: Salesforce Functions can be enabled for a DevHub org. It requires a Salesforce Functions license
    • Frameworks: Open-source or third-party frameworks can be used to save development time and effort
    • Languages: Functions can be written using JavaScript, TypeScript, or Java code that uses Salesforce Functions SDKs to communicate with the org
    • Deployment: Functions can be deployed in a secure and serverless auto-scaling environment using simple Salesforce CLI commands

Ant Migration Tool

  • AKA the Force.com Migration Tool, this Java/Ant-based tool can be used to move metadata between environments via a command line interface
    • Command Line Tool: Command line tool that can be used to migrate metadata between related or unrelated environments
    • Manifest File: The components that need to be moved are described in a package.xml file
    • Local to Remove: ANT-based utility that deploys metadata (in XML format) from a local directory to a Salesforce org
    • Process Automation: The tool’s scripted nature makes it easy to deploy the same components to multiple environments
    • Retrieve and Deploy: The Ant migration tool can be used to retrieve and deploy components
    • Schedule Deployment: Deployments can be scheduled, running the deployment script at a certain time
  • The Ant migration tool uses a build.properties file for pointing to a Salesforce environment where a username, password, and url of the org can be specified

  • Below shows a sample package.xml, or project manifest, which is a file that lists the components to retrieve or deploy

  • build.xml file contains ANT commands which instructs the tool what operation to perform

  • Destructive Changes: Ant Migration Tool can be used to delete components
    • Add and Delete: It is possible to add and delete components in a single deployment. For this use case, the package.xml file lists the components that need to be added or updated
    • Manifest Format: The format of the delete manifest is the same as package.xml, except that wildcards aren’t supported
    • Delete Manifest: In order to delete files, a delete manifest called destructiveChanges.xml is created
    • Deploy Changes: To deploy destructive changes, a package.xml file is also required, which should include the API version, not list any components for deployment, and be in the same directory as the destructiveChanges.xml file
    • Bypass Recycle Bin: The purgeOnDelete option can be set to true to bypass the Recycle Bin
  • Propagating Destructive Changes: Destructive changes can be propagated from one Developer Edition org to another using the Ant Migration Tool
    • Create Empty File: An empty destructiveChanges.xml file is created and checked in to the source code control system
    • In order to delete a component, an entry for the following is added to the file
      • Member: Name of the metadata component member (For example, Shipment__c for a custom object)
      • Type: Name of the metadata component type (For example, CustomObject)

Metadata and Tooling API

  • Metadata API: allows retrieving, deploying, creating, updating, or deleting customizations from an org
    • Related or Unrelated: It can be used to deploy metadata changes from a sandbox, or unrelated org such as a Developer Edition org, to a production environment
    • Metadata API Tools: The functionality in Metadata API can be accessed with the help of two tools, namely, Salesforce Extensions for Visual Studio Code and Ant Migration Tool
    • Common Usage: Metadata API is most commonly used to manage customizations and building the tools for managing the metadata model

  • Tooling API: Tooling API is used for fine-grained access to an org’s metadata
    • Metadata Types as SObjects: Metadata types are exposed as sObjects, so only one component of a complex type can be accessed, making it easier to use than Metadata API
    • Improve Performance: The Tooling API retrieves metadata in smaller pieces which improves performance
    • System Integration: It is typically used for integrating Salesforce metadata with other systems and developing interactive applications
    • Other Applications: Other use cases include source control integration, continuous integration, and deployment of Apex classes or triggers
    • Build Custom Tools: Custom development tools for Force.com applications can be built

  • Table below highlights some of the differences between Metadata and Tooling APIs

  • Metadata Coverage Report: shows which Metadata API types are supported in the Metadata API, source tracking, unlocked packaging, and other channels
    • Latest API Version: The dynamically generated report provides coverage information for the latest API version supported** by the org
    • Access the Report: The report can be accessed by going to https://ORG_URL/mdcoverage/report.jspwhere where ORG_URL should be replaced with the base URL of the Salesforce org
    • Sample coverage report below shows the metadata type and the supporting channels

Unmanaged Packages

  • Unmanaged packages: can be used to distribute open-source projects or application templates for developers to evaluate, enhance, or extend
    • Component Bundle: A package is a bundle of components that make up an App or contain a piece of functionality
    • Package Contents: Typically, a package would contain Objects, Fields, ApexCode, Page Layouts, and Reports
    • Single or Multiple: Packages may contain a single component (e.g. an Apex class) or multiple components
    • Bundle Distribution: Packages are primarily used for distribution across Salesforce orgs
    • Related Components: Packages help by clustering related components together for code migration
    • One-Time Distribution: Can be used for one-time distribution of code and configuration
    • Unrelated Environments: Can be used for code migration between unrelated environments
    • Install via AppExchange: Can be used to distribute to other companies or users via the AppExchange
    • Customizable Metadata: The installer gets a copy of the components, and then can further customize as required
    • No Automatic Updates: Once an unmanaged package is distributed, the author of the code/package will no longer have control
    • Not Used for Updates: Unmanaged packages cannot be used to update existing components and applications
  • Package Manager in Setup is used to manage components and upload the package

  • Considerations when using Unmanaged Packages:
    • No Protection: should not be used if the code being shared is intended to be protected intellectual property
    • No Control: The unmanaged packages can be distributed via a link, but the distribution cannot be controlled. So, a link may be re-distributed multiple times without limits
    • No Namespace: The namespace of the original publishing org is not used** in an unmanaged package; that namespace is removed** from all components when the unmanaged package is uploaded

Managed Packages

  • Managed Packages contain a collection of application components that are published and installed from AppExchange as a single unit a collection of application components that are published and installed from AppExchange as a single unit:
    • Protected: Source code of managed packages is protected and not available to customers
    • Licensing: AppExchange and License Management Application (LMA) allow developers to sell and manage user-based licenses to the app
    • Upgradable: The package author can offer upgrades to the package. When an upgrade is available, customers can update the version installed in their org.
    • Non-Destructive: Certain destructive changes, like removing objects or fields, cannot be performed
    • Commercial: Managed packages are typically used by Salesforce partners to distribute and sell applications to customers on the AppExchange
    • Developer Edition: Developer Edition is required for creating a managed package
  • Following shows an example Developer Edition Org that is set up for creating a managed package

  • Considerations when deciding to use Managed Packages to distribute applications
    • Building Packages: Managed packages can be built using two ways: first-generation packaging (1GP) and second-generation packaging (2GP)
    • Versioning & Patching: Managed packages support built-in versioning support for API accessible components, the ability to branch and patch a previous version, and the ability to seamlessly push patch updates
    • Unique Naming: Unique naming is used for all components in a managed package to ensure conflict-free installs
    • Unpackageable Components: Not all components can be included in a managed package. Unsupported components should be configured manually in the destination org
    • Upgradeability & Deletion: Not all components are upgradeable, subscriber deletable, and/or developer deletable
    • Protectability: Only some components can be marked as protected or automatically include intellectual property protection
    • Recall: Once components have been made available on AppExchange, they cannot be recalled from anyone who has installed them
    • Component Behavior: The component behavior depends on the type of component and can impact app design and distribution requirements. For example, required and universally required custom fields should have default values
    • Custom Objects: Custom objects in a managed package don’t count towards the limit associated with a user license, as long as they are made publicly available on AppExchange

Workbench

  • Workbench can be used to retrieve and deploy components:
    • Manifest File: A paackage.xml file is used to list the components
    • Deployment Results: results of a deployment are available in a zip file for download
    • No Official Support: workbench is not an officially supported app
  • Package XML File: a package XML file is used to define which metadata to retrieve or deploy

  • Results of a retrieve operation can be downloaded as a zip file

  • Results of an operation can be downloaded as a zip file. Below shows sample results from a retrieve operation.

Performance Assistant

  • The Performance Assistant provides resources for understanding what performance and scalability are, and facilitate in conducting performance testing in the org, which involve the following three phases
    1. Prepare: Learn what scalability is and how it impacts application performance, user experience, and productivity. Understand what performance testing is, why it is important, and how it can be conducted.
    2. Execute: Define the necessary test cases and generate a test plan that specifies the number of Inbound Requests, API Calls, and Average Test Iteration Time Per User. Once ready, submit a case to have the performance test scheduled for execution
    3. Analyze & Optimize: After tests are executed, use standard tools that help analyze and interpret the test results. Determine the recommendations for optimization using Salesforce Optimizer. Integrate performance testing in release cycles

  • Search performance to find the Performance Assistant page in Setup