Package Development Model

Imagine a New Source of Truth

Describe how the models for change set and org development differ from modular package development. List the advantages of package development. Describe the key characteristics of a package.
  • Typical for orgs to first move to Declarative Change Set Development to help manage change, and then to Programmatic Change Set Development
    • Fast-paced orgs with many developers can run into issues tracking changes, because your changes intermingle with what others have changed, so the tracking process can become tricky and somewhat manual.
      • Note in the example below the “Time Off Manager App” must be deployed to the org at the same time as other generic “CRM Extensions/Customizations”

  • In particular, if there are multiple development teams and multiple admin teams, it might be helpful to decouple projects from the huge “release train”. Benefits:
    • Improving team development and collaboration.
    • Modular development process with specification of dependencies among packages.
    • Versioning to help with change management
    • Facilitating automated testing and continuous integration.
    • Making the release cycle more efficient and agile.
    • Improved version control system (VCS) synchronization through change-tracking of Setup features
    • More fine-grained visibility and clarity into the change management of your production org
  • Practically, moving to a package development model means that instead of building code and customizations for an entire org, you create a package (logical set of code).
    • A Package is a release artifact that is a group of related code and customizations.
    • Orgs then become organized into a set of packages, which makes more clear the relationships between the various metadata components in the org.
    • Gives more flexitiblity in managing teams and releases, and dev teams can develop separately and build toward release of a package, and not a release of the whole org.
      • This agile model enables more frequent, independent releases.

  • A version-control system plays an important role in the package development life cycle. All source for packages is stored in a source control repository, where the source of truth is maintained. Scratch (development) orgs are built from that source.

  • What is the source of truth for package development?
    • Version control system
  • What are the advantages of package development?
    • Ability to build development orgs directly from source
    • Agile release models allow more frequent, independent releases
  • What’s included in a package?
    • A group of code and customizations you want to release together

Increase Productivity with Integrated Tools

Describe the ways in which the Salesforce Command Line Interface (CLI) can enhance productivity. Describe the role of version control systems, scratch orgs, and sandbox orgs in the package development model. Identify when it’s appropriate to use scratch orgs vs. sandboxes.
  • Some tools used for Salesforce development are commonly used (Eclipse and ANT). Others are unique to Salesforce (Change Sets, Sandboxes)

Salesforce Command Line Interface

  • Salesforce CLI can be used to manage the package development process from the command line
    • Combines many capabilities from across several different Salesforce APIs, including: Metadata API, Tooling API, Data (SOAP) API, Ant Migration Tool (allows for scripting of metadata tasks)
    • Enables developers to script everything from creation of orgs to import and export of data
  • Developers can use it to:
    • manage DX Projects,
    • create scratch orgs,
    • push and pull metadata to and from scratch orgs,
    • run unit tests
  • DevOps can use it as part of build automation scripts:
    • create and access environments,
    • deploy source
    • install packages
    • run tests
git clone https://github.com/somecompany/someproject.git
git checkout -b mybranch
sfdx force:org:create -f config/project-scratch-def.json
sfdx force:source:push
sfdx force:org:open

Salesforce Extensions for VS Code

  • Provides a powerful IDE created especially for custom development on the Lightning Platform. Includes:
    • Functionality to interact with the Salesforce CLI
    • Functionality to create projects for your package development
    • Access to the Apex Language Server for syntax highlighting and code completion
    • Support for Lightning component bundles
    • Support for Visualforce pages and components
    • Support for interactive and replay debuggers
    • Git pre-integration, but can also work with other version control systems

Version Control System

  • Example: Git and GitHub. These are the heart of source-driven development.

Scratch Orgs

  • Scratch orgs are dedicated and configurable Salesforce environments that are designed to be ephemeral and easily recreated.
    • Designed to be your own personal development environment so you have your own “sandbox” without any other kids
  • “Spin up” a new scratch org when you want to:
    • Start a new project.
    • Start a new feature branch.
    • Test a new feature.
    • Start automated testing.
    • Perform development tasks directly in an org.
    • Start from “scratch” with a fresh new org.
  • Scratch orgs can have different Salesforce editions and specific features and preferences

Scratch Orgs versus Sandboxes

  • Scratch orgs don’t have the capacity to contain the entire set of metadata in a production org, and are not meant to replace Sandboxes
    • If metadata you want to push to a scratch org represents logs of different apps or projects, it may make sense to think about how to split them up into different packages. Scratch orgs would be created to test each of those individual modules.
  • Sandboxes are still the right place for testing the installation of the package versions you create, and for user acceptance testing, as a staging environment, and continuous delivery testing.
  • Scratch orgs should be used for source development use cases. Sandboxes should be sued for release and deployment testing.

  • Scratch orgs provide:
    • A dedicated and disposable Salesforce environment for a developer and their project
  • What is the role of sandboxes in the package development model?
    • You use sandboxes for user acceptance testing and as a staging environment
    • Where you test your package during continuous delivery testing
  • How does the Salesforce CLI increase your productivity?
    • You can create scripts for repetitive tasks, for build automation, or to run tests

Understand Source-Driven Development

Describe the purpose of a Salesforce DX project. Describe how the package development model helps you manage change tracking. Explain the role of scratch orgs in the development process.
  • As the organization grows, its common for teams to experience challenges around coordinating and testing changes across projects using change sets.
    • Package development addresses those challenges directly.
    • Source is organized into packages based on a group of features to be delivered together.
    • Salesforce DX project reflects this package-based approach to organizing source code.

Salesforce DX Project

  • A Salesforce DX project is a local directory structure of metadata in source format. It enables develoeprs to develop and test with Salesforce DX tooling. It includes (or can include):
    • Config files for creating scratch orgs
    • Data to be loaded into orgs for development (can include)
    • Tests that you rely on to validate the package
  • The CLI creates the Salesforce DX project for the user. Many things are created:
    • Base project configuration file
    • Sample scratch definition files and directories for your tests and sample data sets
    • Default “package” directory for package source
  • Metadata components within a package can live in only one package at a time in the installed org
  • A DX project manages the source for one package, at minimum, but if multiple packages get built and released together, those packages can be combined into a single DX project.
    • Each package aligns to a package directory defined in the project configuration file.

Scratch Orgs

  • While the IDE is available for programmatic development, you can also use the scratch org for declarative development.
    • Process is similar to what we did in the sandbox or production org. Difference is that in the source-driven model you synchronize any development you did in the scratch org with the local project.
      • This synchronization lets you commit changes made in the Setup pages alongside programmatic changes made in the local IDE.
  • Before committing its important to run tests - these can be done in the same scratch org, or by spinning up another one specifically for testing before committing.

Syncing

  • Key feature of Salesforce DX is that it easily keeps the project and scratch org in sync. With this paradigm, no longer required to manually keep track of changes.
$ sfdx force:source:status
STATE                     FULL NAME    TYPE        PROJECT PATH
─────                     ──────────   ──────────  ─────────────────────────────────
Local Deleted             MyClass      ApexClass   /MyClass.cls-meta.xml
Local Deleted             MyClass      ApexClass   /MyClass.cls.xml
Local Add                 OtherClass   ApexClass   /OtherClass.cls-meta.xml
Local Add                 OtherClass   ApexClass   /OtherClass.cls.xml
Local Add                 Event        QuickAction /Event.quickAction-meta.xml
Remote Deleted            TempClass    ApexClass   /TempClass.cls-meta.xml
Remote Deleted            TempClass    ApexClass   /TempClass.cls.xml
Remote Changed (Conflict) NewClass     ApexClass   /NewClass.cls-meta.xml
Remote Changed (Conflict) NewClass     ApexClass   /NewClass.cls.xml
  • Production orgs can have enormous source files.
  • DX project format breaks down large source files to make them more digestible and easier to manage with a VCS.
    • Example: transforms custom objects and custom object translations into multiple files and directories, making it easier to find what needs to be changed or updated.

  • Salesforce DX project:
    • Contains your source and Salesforce DX configuration files
  • How do we facilitate change tracking?
    • Transform large source files into smaller ones, providing more project flexibility and reducing merge conficts
    • Keep track of both changes made locally as well as any in the scratch org
  • Use scratch orgs in the development process to:
    • Perform declarative development and other tasks directly in an org

Learn How to Test, Build, and Release

Describe how scratch orgs support various types of testing. Describe the role of sandboxes in deployment.

Continuous Integration Using Scratch Orgs

  • In change set development, developers move org changes (deltas) between development and test environments until those changes are released to production.
    • At the end of the day, the “source of truth” is the production org.
  • In the package development model, the new and improved source of truth is the version control system.
    • Use Salesforce DX projects to organize source into package directories.

  • (1) When ready to perform manual testing of development work, push the metadata into a scratch org designed for that.
  • (2) Continuous Integration (CI) is about automating consisten test runs against every set of changed merged into the application.
    • Scratch orgs can be integrated into a CI process - the CLI can create scratch orgs, so scripting them into a CI flow is easy.
    • Scratch orgs can be created through the day (as opposed to a single refresh per day)
      • Provide lots of flexibility with limited overhead
  • (3) Instead of using changes sets to move changes between environments, you create and install package versions in each testing environment. Once testing is complete, you install a package version in production.

  • How do scratch orgs support testing and continuous integration?
    • You can spin up a new scratch org specifically for testing and CI.
  • Use sandboxes for continuous delivery and user acceptance testing to:
    • Test the same process that will be used to deploy and release to the production org.

Plan Your Move to Packages

Identify use cases where you can shift to a modular (package development) approach. Identify a scenario that doesn't lend itself to package development.
  • It used to be that packages were for just partners who built and distributed applications on AppExchange. Now, for enterprises and customers, there are unlocked packages.
    • Unlocked packages are ideal for contractors, consultants, and systems integrators.
  • Important step for moving to packages is to look for distinct applications in the production org that are separate from everything else. If these are maintained by distinct teams, those can be isolated into their own packages.
  • If metadata is shared by multiple applications, recommend to organize those shared components into a single base package.
    • This way, you can ensure that all packages can reference the components in the shared base package.
  • Once the packages are identified, use the Metadata API to retrive the source related to your package. There are trailhead modules on this topic.
  • If an org is more mature or more complex, the shift to packages needs to occur over time.

Resources