We’re well into 2024 and there’s no better time to reflect on your team’s build and deployment processes. While Salesforce can be an incredible platform to build enterprise-grade applications on, deploying solutions on Salesforce has been known to have its challenges.
Fortunately, over the past several years, Salesforce has invested greatly in improving the application development experience. Unfortunately, the methodologies these investments enable are seldom leveraged outside of the ISV ecosystem. With scratch orgs, the Salesforce CLI, CumulusCI (thanks SFDO!), and second-generation packaging, the Salesforce community has been given the foundational tools needed to build robust test and deployment automations. We no longer need to rely on change sets, 3rd party “DevOps” platforms, or the Ant Migration Tool to safely, reliably, and scalably promote our applications to production.
We no longer need to rely on change sets, 3rd party "DevOps" platforms, or the Ant Migration Tool to safely, reliably, and scalably promote our applications to production.
Scratch Orgs
Scratch orgs, unlike sandboxes, are ephemeral, and exist for up to 30 days. They’re (relatively) cheap to provision and are used in several workflow automations. Learn more on the Salesforce Developers site.
Cumulus CI
Cumulus CI, developed by the team at Salesforce.org, is an application that sits atop the standard Salesforce CLI that provides a valuable toolbox of automations for package development, testing, and data generation. Learn more here. |
Second-generation packaging
Second-generation packaging enables unlocked and org-dependent unlocked packages. These package types are “subscriber-editable” which means that their metadata can be updated post-installation. Learn more on the Salesforce Developers site. |
Why is deployment so difficult?
Org-based development and deployment on the Salesforce platform can be challenging for a number of reasons, primarily because deployments are almost always irreproducible. Given that each Salesforce environment is a unique combination of metadata, data, and environmental quirks, it’s extraordinarily difficult to completely test a deployment without actually deploying.
What we find is that when building on Salesforce, you’re paying two costs with each deployment:
- The cost of dependency verification (validating that what you’re deploying has everything it needs, like custom objects and fields).
- The cost of testing (both automated Apex tests and manual tests).
By adopting second-generation package development, we’re able to pay and lessen these two costs much earlier in the development lifecycle. We’re able to validate that a package will build and install, and our tests will succeed months before a go-live date.
Deciding to move towards package-based deployment enables your team to automate common tasks like:
- Development and test org setup: ensure that your team is building in a development org constructed from a blueprint with all necessary dependencies installed!
- Data seeding: ensure that your team is all building against a common dataset without customer information!
- Testing: automate the execution of front-end and back-end tests in Apex + Jest, along with end-to-end tests using the Robot framework!
- Package Version Management: Trigger new versions on approved changes, there’s no need to execute the commands manually.
- Deployments: Once a package is promoted, automate its installation into a target org at a given time.
How do I get started?
It most likely took several years, if not more than a decade, for your Salesforce org to achieve its current state. Untangling its metadata is not a quick undertaking. Decomposing your org into smaller modules of related metadata takes careful planning and a little patience. For some, org-dependent unlocked packages may be a great starting point.
If you’re not already leveraging version control, this is your first step. Create a remote repository (we use GitHub due to the CumulusCI compatibility requirement) and commit your org’s metadata to it.
Next, let’s head to the drawing board to identify the primary business functions our Salesforce org supports. This is the most challenging part of adopting a package-based development model. In each of these functions, identify and document the key customizations and features you and your team have built. You may find that some objects, fields and permissions are shared by more than one function. That’s okay! We should take special note of these common components. Once these key features have been documented, we can return to our repository and begin reorganizing our metadata! Instead of chucking everything into `force-app/main/default`, let’s create dedicated folders for each category of function and start moving relevant metadata into these folders (e.g. custom objects, permission sets, flows, etc.).
Once you’ve completed this, your folders will likely become your org’s packages! You may have one that extends core Sales Cloud and CPQ, one for your Support vertical, and one that enables a customer-facing portal. With these in place, your next step is to begin packaging – have fun!
At Rosetree, we leverage GitHub actions with CumulusCI to enable our packaging and development workflow automations. Check out this public repository for examples of GitHub actions we employ. If you have any questions or need a hand getting started, please don’t hesitate to reach out.
For expert solutions and support, reach out to Rosetree Solutions, your trusted 5-star AppExchange partner.
Jesse Wheeler, Technical Architect
With 8+ years of experience in the Salesforce ecosystem, and several more years writing software programs across multiple technology stacks and frameworks, Jesse brings a passion for solution engineering and problem solving to all of his projects.