Salesforce Deployment & Environment Management – Best Practices
Feature Development Methodologies
There are two primary approaches for developing features on the Salesforce “core” platform:
Org-driven development
The organization that is replicated into Sandboxes is the “source of truth.” The conventional DevOps model on Salesforce
Source-driven development
The code versioning mechanism is the “source of truth.”
The Salesforce DX-powered model
Environments overview
When to use which type of environment – summary
Metadata API
Standard platform API used to: retrieve, deploy, create, update or delete customization
information from and to a Salesforce org (e.g. custom object definitions, code
components etc.)
It is NOT used for managing records (e.g. create accounts)
Accessed through
• Salesforce Extensions for Visual Studio Code
• Ant Migration Tool
Metadata types and API specifics
• Not all metadata types are supported through the API (https://developer.salesforce.com/docs/atlas.enus.api_meta.meta/api_meta/meta_unsupported_types.htm)
• Metadata Coverage Report (https://developer.salesforce.com/docs/atlas.enus.api_meta.meta/api_meta/meta_coverage_report.htm): per metadata type, deployment way (packaged,
change sets, Apex Metadata API)
• Some metadata components have specific behaviours on deployment through the Metadata
API (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_special_behavior.htm)
Metadata API – Usage
Manage setup and customization information (metadata) for your
organizations
• Export the customizations in your organization as XML metadata files
• Migrate configuration changes between organizations: deploy and retrieve
• Modify existing customizations in your organization using XML metadata files: deploy
and retrieve
• Manage customizations in your organization programmatically:
o Use CRUD-Based calls to create, update, or delete setup and configuration
components (e.g., custom objects, custom fields, other configuration metadata)
o The metadata calls mimic the behaviour in the Salesforce user interface for
creating, updating, or deleting component
Conventional characteristics deployment capability
The new developer experience is Salesforce DX.
A brand-new source code-based approach to managing and creating apps on the Lighting Platform over their whole lifecycle
How to get started with Salesforce DX:
Install and set up an IDE (such as Visual Studio Code and the Salesforce Extensions for VS Code), activate DevHub, install the Salesforce CLI, and connect with a source control system (such as GitHub).
Establish a repository, develop an application, import or migrate the current source, use an existing package, and describe unpackaged configuration in a package.xml file.
Tools and Application Lifecycle Management
Continuous development with Salesforce DX
Feature Development Paths – 2 methodologies
Packages on Salesforce
It can be shared with other Salesforce users and organizations, even those outside the original company, and serves as a package and container for relevant Salesforce components.
A component is a part of a package that defines an item, like a custom field or object.
Features • A component’s field
Package Types
Packaging advantages and capabilities
Using packages to organize a production organization
Feature Development with Packaging
Dev Hub – Scratch orgs management
- Establish and oversee scratch organizations
- Develop and oversee second-generation packaging
Environment Hub: Management of Organizations
Capabilities:
- Setup & Configuration
- View Orgs
- Create Orgs
- Login & SSO
- Connect Orgs
