How to Use MuseLab D2X to Supercharge Salesforce DevOps Workflows
Last time, I introduced MuseLab D2X and why we built it to help Salesforce developers more easily build Well-Architected DevOps that leverage the full power of GitHub and CumulusCI. In this follow-up, I’ll walk through the step-by-step process of kicking off a new project with D2X Launchpad, so you can see how simple — and powerful — this new approach can be.
Table of contents
Let’s Get Started!
Ready to dive in? D2X Launchpad provides a user-friendly web interface to launch new GitHub repositories, fully configured for D2X. Once you’ve set up your GitHub repository, the D2X Project Tutorial offers a step-by-step guide to finalizing your project’s setup and getting started with development.
You’ll need to complete some one-time setup in GitHub that works for all your D2X projects:
- Collect credentials to Salesforce DevHub
- Collect credentials to GitHub
- Create GitHub Actions secrets
- Create GitHub Codespaces secrets
Every D2X project you create is then automatically connected to your DevHub and GitHub to run a fully automated software development lifecycle with GitHub as the source of truth. Your team only needs to learn a few commands using the CumulusCI command line interface, cci, to type into the GitHub Codespaces terminal:
- Create GitHub repository with D2X Launchpad
- Fire up your first Codespace and start developing package in a feature branch
- Create a dev org
cci flow run dev_org- Open the org and make changes:
cci org browser- List, filter, retrieve using source tracking:
cci task run list_changes
cci task run list_changes --include CustomField
cci task run retrieve_changes --include CustomField- Capture all the data in the org as the project’s initial default sample dataset. This will then load automatically into all new scratch orgs
cci task run capture_sample_data- Or, capture all the data in the org as the project’s qa dataset, which are loaded into new qa scratch orgs.
cci task run capture_sample_data --dataset qa- Commit and push: Pushes kick off automated Feature Test builds
- Create a Pull Request to merge the feature branch to main
- Merges kick off beta package creation (if using packaging)
- Run the Production Release GitHub Actions workflow to create a production release
D2X & CumulusCI
Much of D2X’s functionality comes from CumulusCI, an open source Salesforce automation framework built by Salesforce.org over the last decade to handle the unique DevOps requirements of some of the most installed ISV packages on the platform: Salesforce’s Nonprofit Cloud and Education Cloud. I had a front-row seat to the creation of CumulusCI, having founded and led the team that continues to develop CumulusCI today at Salesforce.
CumulusCI is a robust, mature automation orchestration framework that replaces shell scripts with a YAML configuration. CumulusCI’s universal configuration provides a best-practices default configuration which projects override and extend to define their product automation recipes. Covering all of CumulusCI’s functionality here is beyond the scope of this article, but there are links in the Resources section to more about CumulusCI.
D2X makes CumulusCI more accessible to the ecosystem by wrapping it in a common Docker-based runtime environment and providing preconfigured project templates and reusable workflows that ensure your project uses the full capabilities of CumulusCI.
Universal and Project Configuration
A project’s automation configuration is core to CumulusCI’s functionality. You use CumulusCI’s Universal Configuration to start the project. You can learn a lot about CumulusCI by reading through the Universal Configuration’s cumulusci.yml. That’s the starting point for all CumulusCI projects. It bakes in proven best practices for a fully source control based lifecycle that provides most of what your project needs out of the box.
But CumulusCI can’t really know the needs of your particular project. It provides a framework for defining the automation specific to your project. Each project has its own cumulusci.yml file that contains its extensions and overrides of the Universal Configuration to create the Project Configuration. The project’s cumulusci.yml is then automatically merged on top of the Universal Configuration. This constructs the Project Configuration that is used by client applications like cci, which is the command line interface for running CumulusCI automation.
This approach has many advantages:
- Consistent set of commands that works across repositories so users need to learn a few commands to be productive
- Command consistency allows for reusable CI/CD scripts applied to many repositories with low overhead
- Projects can wire in custom automation unique to the project in the cumulusci.yml file
- Use of composable objects enables reuse by other projects
Release Operations Automation with CumulusCI
CumulusCI includes full release operations automation for package based development, eliminating the operational cost of product releases. CumulusCI creates release artifacts in the GitHub repository using commit status (feature test packages) and tags and releases (beta and production releases).
For 2GP release operations specifically, CumulusCI provides a significantly improved developer experience. Gone are the days of manually creating packages, copying package ids, copying package version ids, and manually managing dependencies.
D2X Launchpad pre-configures GitHub Actions builds that run the relevant CumulusCI release operation flows as changes are made to the repository.
Dependency Management with CumulusCI
The release artifacts created by release operations automation can then be used by CumulusCI’s dependency management to create a recursive package dependency manager, allowing a project to define a dependency on another project’s GitHub repository. CumulusCI dynamically inspects dependencies at build time to find their latest release and all of that release’s dependencies recursively. CumulusCI’s environment automation recipes use the dependency manager to automate installing all dependencies into scratch orgs, allowing seamless composable development.
For example, the following lines in a project’s cumulusci.yml file specify a dependency on the popular open-source Distributed Lookup Rollup Summaries (DLRS), which is itself built with CumulusCI:
project:
dependencies:
- github: https://github.com/SFDO-Community/declarative-lookup-rollup-summariesWith this simple change, the project is now defined as an extension that depends on DLRS. All scratch orgs built using CumulusCI will automatically have the latest version of DLRS installed. This simple example demonstrates a unique superpower of CumulusCI that is especially useful when approaching the Well-Architected concepts of Composability and Packageability.
CumulusCI’s Custom Task Framework
Finally, CumulusCI has a custom task framework for implementing any custom automation your project needs. CumulusCI comes with many tasks to automate common operations, but that doesn’t have to limit you. CumulusCI provides an extensible framework for building Product Delivery Model recipes in source control so you can reliably deliver complete product experiences of all your projects to new or existing orgs.
Conclusion
In the dynamic world of Salesforce, staying ahead of the curve is crucial. With the Salesforce Well-Architected Framework as our guide and MuseLab D2X as our tool, achieving a robust and efficient DevOps process has never been easier. Whether you’re a seasoned Salesforce developer or just starting out, D2X offers the tools, resources, and guidance to ensure your projects are well-architected, adaptable, and ready for the future.
