Unlock the Full Potential of your Salesforce Org with Modularisation and DX@Scale
Streamline your Salesforce application lifecycle by enhancing the experience of your developers and admins.
Trusted and used on more than 150 Salesforce production orgs
Open-source and battle-tested.
We have been early adopters of Salesforce DX and saw it as a massive step towards improving the developer/admin experience. The version control system was finally the source of truth, and we loved it.
We wanted to take it to the next level and apply Continuous Delivery principles to Salesforce. We have defined an approach and a set of practices, and we have developed a set of tools to support them.
We have open-sourced all of that. DX@Scale is now used on more than 150 Salesforce Production Orgs worldwide. We are grateful that some of these users allowed us to use their logos.
There is no trade-off between quality and speed
DX@Scale is a different approach to Salesforce development.
We had several sessions like this one where we talked about our approach to building modular Salesforce Orgs: when we focus on sane Software Engineering principles like modularisation, trunk based development, continuous integration and the right tooling, we can build and maintain any org at any scale, with consistency, confidence and high level of quality.
Results observed in the trenches
What it could look like for you.
We use DX@Scale on a multi-year Salesforce program involving Sales Cloud, Service Cloud, Revenue Cloud and several integrations with Front-End and Back-End Systems. This is what we have observed so far.
Our community users achieve similar results when they follow our approach and use our open-source tools.
Since we adopted DX@Scale, it has been the best time and effort investment for our Salesforce delivery pipeline. To make it even more precise: I can't imagine working with other CI/CD solutions on this platform in the future. Roughly, our team's velocity has been multiplied by 3.
Increased Efficiency
- By breaking up a your Salesforce Org into smaller, independent modules, developers can work on specific project parts simultaneously, speeding up the overall development process.
Better Maintainability
- Because your modules are smaller and independent it is easier to identify and fix bugs or issues that may arise. Additionally, it is easier to update or refactor individual parts without affecting the entire codebase.
HappySoup™
config
force-app
appMenus
applications
aura
classes
contentAssets
flexipages
flows
layouts
lwc
objects
permissionsetgroups
permissionsets
profiles
quickActions
tabs
triggers
sfdx-project.json
sfdx-project.json
{
"packageDirectories": [
{
"path": "force-app",
"default": true
}
],
"name": "happy-soup",
"namespace": "",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "56.0"
}
DX@Scale led us to scale from one release every two weeks to release daily. Salesforce Development has an ocean of know issues and trade off, DX@Scale cover all of them, saving a lot of time of scripting/hacks development. Salesforce Modularity is possible, It takes time, It pays off; DX@Scale help us to achieve it.
Not just another tool
DX@Scale is about simplifying your Salesforce development experience.
DX@Scale is not just another tool. We advocate for sane enginering practices applied to Salesforce, and we have built and open source all the tools to support them.
The first step that we recommend is to assess the level of technical debt in your Salesforce org. Then start modularising it. We know this is a painful exercise, but it is really worth it.
The more modular and composable your Salesforce org is, the faster you'll become. No module is too small...
Be mindful that depending on the size of your org, this exercise could take several months. Take tiny steps, extract, assess, rinse and repeat.
DX@Scale
config
packages
billing
products-pre
products-post
case-management
case-config
case-entitlements
case-management
web-to-case-api
marketing/marketing-preferences
classes
customMetadata
test
README.md
sfdx-project.json
sfdx-project.json
{
"packageDirectories": [
{
"path": "packages/billing/products-pre",
"package": "billing-product-catalogue-records-pre",
"versionName": "billing-product-catalogue-records-pre-1.1",
"versionNumber": "1.5.12.0",
"dependencies": [{
"package": "Salesforce Billing"
},
{ ... }
]
},
...
{ "path": "packages/billing/products-post", ... },
{ "path": "packages/case-management/case-config", ... },
{ "path": "packages/case-management/case-entitlements", ... },
{ "path": "packages/case-management/case-management-core", ... },
{ "path": "packages/case-management/web-to-case-api", ... },
...
]
}
DX@Scale provides the foundation for us to tame Salesforce’s enormous variety of capabilities and functionalities resulting from it’s high degree of flexibility in configuration. It allows us to combine state of the art approaches to software development with Salesforce, and in particular to implement CI/CD pipelines across multiple customers. We are looking forward to the future with DX@Scale and try to become even more a part of the DX@Scale community.
A journey ahead of you
Not ready to embrace Unlocked Packages? Don't worry, we got your back, and more...
A "Well Architected" Saleforce org enables your business to adapt to change and release new capabilities faster. The end goal, where feasible is to embrace unlocked packages.
However some times, they may seem overwhelming; they may not be the right fit or they lack some capabilities like the support for data-driven packages like Revenue Cloud.
We faced the same challenges and developed capabilities we think you'll appreciate.
Source packages bridge the gap between metadata deployment and unlocked packages.
They are a construct which wraps Salesforce Metadata with meta-information (such as version number, commit id, branch, tag, ...)
We use them, and recommend them in the following cases:
- Metadata not supported by Unlocked Packages
- Dealing with metadata that is global or org-specific in nature (such as queues, profiles, etc or composite UI layouts, which doesn't make sense to be packaged using unlocked package)
- Development teams who are starting to adopt package-based development and want to organize their metadata
sfdx-project.json
...
{
"path": "packages/case-management/case-config",
"package": "case-config",
"versionName": "case-config-1.0",
"versionNumber": "1.0.6.NEXT",
"dependencies": [{
"package": "case-management",
"versionNumber": "3.2.0.LATEST"
}]
}, {
"path": "packages/quote-recalculation-batch",
"package": "quote-recalculation-batch",
"versionName": "quote-recalculation-batch-1.2",
"versionNumber": "1.2.0.NEXT",
"default": false
}, {
"path": "packages/sales/opportunity-management",
"package": "src-sales",
"testSynchronous": true,
"versionNumber": "2.5.17.0"
},
...DX@Scale has been a game changer for our salesforce CI/CD processes. With its streamlined pipelines, automated processes and modularisation, we have been able to deliver faster and more efficiently. The integration of DX@Scale into our workflow has not only saved us time, but has also improved the quality of our deployments. I highly recommend DX@Scale to anyone seeking to improve their salesforce development lifecycle.
Stop fiddling with custom CI/CD scripts
Meet our declarative orchestrator.
As you modularise your application, you would need to update regularly your CI/CD scripts. We know it, we faced the same issue! That's the reason we have created the Orchestrator .
Just modularise your solution, the orchestrator will auto-magically take care of the rest for you.
The orchestrator understands your sfdx-project.json file, and builds your modules in parallel when it is possible:
- You don't have to fiddle with custom CI/CD scripts anymore, just focus on your modules and their dependencies, the orchestrator takes care of everything else.
- Get faster build: if there are no dependencies, or the dependencies have already been met, several modules can be processed at the same time.
sfdx-project.json
{
"packageDirectories": [{
"path": "./es-base-objects",
"package": "ESObjects",
"versionName": "Base Objects - Winter '22",
"versionNumber": "55.0.0.NEXT",
"default": false
}, {
"path": "./es-base-styles",
"package": "ESBaseStylesLWC",
"versionName": "Base Styles LWC - Winter '22",
"versionNumber": "55.0.0.NEXT",
"default": false
}, {
"path": "./es-base-code",
"package": "ESBaseCodeLWC",
...
}, {
"path": "./es-space-mgmt",
"package": "ESSpaceMgmtLWC",
...
}],
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "55.0",
"packageAliases": {
"ESObjects": "0Ho4W000000CaeJSAS",
"ESBaseCodeLWC": "0Ho4W000000CaeTSAS",
...
}
}
DX@Scale is a powerhouse. It gives Salesforce architects a rich devops framework that uses design patterns and pipeline actions more familiar to software engineers who have worked in “regular” devops. While focused on its own development methodology, DX@Scale has components of value to any software engineer working in Salesforce. With this suite of tools and capabilities, DX@Scale helps enterprises leapfrog into a modern app development methodology.
Build, measure, assess, rince and repeat
You can only improve what you measure.
Metrics should be a key part of any development process. That's the reason why DX@Scale is instrumented.
DX@Scale exposes metrics that track counts, duration, success rate for all the phases of your CI/CD.
By monitoring these metrics you can than identify the bottlenecks in your process and act accordingly.
For instance:
- Is your build taking too long? Perhaps there is a dependency that you can invert.
- Are your unit tests taking too long? This is usually an issue with your tests not being isolated enough.
- Are your deployments failing too often? Perhaps you are missing some automation when deploying to the downstream systems.
Production Install Time
| Package | Metadata Count | Install Time | Average Time |
|---|---|---|---|
sales
| 428 | 12.09 | 7.23 |
service
| 210 | 7.94 | 5.58 |
billing-product-pre
| 28 | 2.39 | 1.23 |
billing-product-post
| 8 | 3.23 | 0.5 |
case-config
| 132 | 2.24 | 4.5 |
case-entitlements
| 48 | 4.17 | 4.23 |
web-to-case-api
| 26 | 7.29 | 3.57 |
marketing-preferences
| 8 | 1.98 | 2.18 |
Last 7 days
- # Pull Requests
- 137 from 118Improved by 16%
- Validation Time in mn
- 14.41 from 15.13Improved by -4.1%
- Success Rate
- 60.87% from 70.62%Deteriorated by -13.8%
- Feedback Time in mn
- 11.9 from 13.2Improved by -9.8%
Speed up your workflow
Provision scratch orgs in seconds not hours.
As you automate more of your business processes in Salesforce, you cannot avoid adding third party managed packages as a dependency to your configuration metadata and code in your repository.
The time required to spin up a new CI or a developer environment increases, diminishing the value of using scratch orgs. We have seen teams avoiding scratch orgs for that.
We think scratch orgs are amazing, and we solved this problem with Scratch Org pools.
Pools are created of the back of your version control system, meaning extra time saved...
As a developer, you are going to love this (we hope!).
How long does it take to spin up a new scratch org? Install the managed packages required for the new feature you need to build? Minutes? Hours?
Think seconds, no matter how complex your set up is... Simply fetch a new scratch org from the pool and start your new feature. Take the time to grab your favourite drink though!
This is as simple as:
