Our most frequently asked question is probably how we help companies use Salesforce DX more easily. It’s no surprise to us because Salesforce DX is the most exciting announcement to come out for Salesforce development in a long time.
To explain our relationship with Salesforce DX, we use a simple analogy: Blue Canvas wants to be the GitHub to Salesforce DX’s Git. As we stated in our previous post:
Git is an amazing open source tool that helps software teams collaborate in a distributed way. There are so many benefits to using Git. But Git didn’t really take off until GitHub built a hosted service that made Git more easily available to people. A hosted version of Git meant that teams no longer had to set up and maintain Git on servers or worry about maintenance and downtime. With GitHub, Git just worked. This facilitated a revolution in how teams collaborate to build software.
As we have spent more time with Salesforce DX, we’ve noticed that it is indeed like Git in a number of ways. It’s a command line driven tool that is enormously important for developers, but it can be a little bit tricky to set up. DX is in many ways plumbing to help empower your developers to create custom solutions. We believe that Blue Canvas provides a layer of UI on top of DX that generates a lot of the benefit of DX without the hassle of setup.
One of the first things that we help with is converting your metadata structure to use DX without doing any of the hard work yourself.
With our latest release, Blue Canvas now automatically allows users to get the benefit of targeted tracking and deployments in Salesforce without having to change anything about your orgs.
We thought we’d write a little Q&A to help explain in more detail.
What are the benefits of the new DX directory format?
Salesforce DX has a new directory format which helps modularize your metadata.
Modula-what my metadata?
Modularize. It basically allows you to break down metadata into smaller components or modules that are more manageable. For example in the old format, an object is treated as one giant XML file like this:
With the DX format you actually convert the XML into a directory of it’s own with smaller xml files inside. So now that custom Book__c object is a folder with smaller files for each field.
Why does this matter?
This is great for a few reasons. It lets you track changes at the field level. So you can rollback and revert at a more precise level rather than at the file level. It lets you audit what is going on in a more precise and accurate way.
You can also deploy more cleanly. When you are just updating a single field why should you deploy changes to other unrelated fields? With this new format you can deploy a single field which is a lot faster than trying to deploy an entire component. Plus it helps with avoiding merge conflicts and code clobbering (aka unwanted overwrites).
How will this help with merge conflicts?
Let’s say two admins or developers are working on the same Object but on different fields. If you deploy an entire file, you will probably overwrite the work of the other person. But if you’re using a more modular approach, you can deploy just the field that you were working on. (Blue Canvas has other checks in place to prevent code clobbering as well for what it’s worth).
How do I convert to this format?
You can do this yourself by following the Salesforce DX docs.
However, we’ve seen a lot of teams struggle to convert existing projects to DX, especially legacy projects. Many orgs we work with are over a decade old and have large amounts of legacy code in them. And most teams have deadlines from their business stakeholders that make undertaking a massive internal conversion project difficult to prioritize. Even if you had the time, converting to DX has proven hard for many teams.
So Blue Canvas can help me convert to DX automatically?
With Blue Canvas we help manage that conversion for you. We automatically convert your metadata structure to a decoupled DX format so you can start to track and deploy smaller components. One nice thing is that this requires no work on your part. Another nice thing is that you’re not locking yourself into a new format. You can seamlessly deploy back and forth between the new and old formats using Blue Canvas. The directory conversion is purely in your Blue Canvas source control repo and therefore doesn’t affect your existing orgs or lock you in to anything.
What is the benefit to using Blue Canvas to leverage Salesforce DX?
The best thing about using Blue Canvas to leverage DX is that you get all of the DX benefits without the manual setup or maintenance. Using this new set up you can deploy one field at a time or in batches rather than entire files. You can track history and changes on specific fields rather than entire objects. The same goes for Workflow Rules and other similar components.
You can deploy faster and more cleanly because you are only deploying very targeted changes rather than massive changes that invoke unwanted dependencies. And you’ll get fewer merge conflicts for the same reason.
What if my organization is not ready to move to DX?
You don’t have to. Blue Canvas lets you get these benefits without any underlying change to your process or code base. And it’s also optional in the first place.
Can I deploy to orgs that are not using the DX directory structure?
Yes we handle this conversion for you. Again, we take your traditional Salesforce orgs and translate it into the DX format for source control. But when deploying between orgs we can handle that translation so you don’t have to worry about that.
How do I learn more?
Email email@example.com to get a demo!