Salesforce DX is here for a while and enough has already been said and written about it. Even I spoke at Dreamforce how cool it is for admin. Finally I had an opportunity to use it on real project, with several consultants and developers and really see how it works and what are the challenges you might expect.
There were plenty of them, some of them probably because of our processes, the others most likely due to DX/Git philosophy.
Git
DX is not linked with the need of source code versioning, but it makes sense, especially when linked with CI/CD.
For us, as consultants who are used to the idea „your org is yours source of truth“, it was something completely different. You should create a new branch for each story (what should be story, is creating two fields on the same object one story or two, what about field and list view?), then push it to scratch org, do changes, pull, push to git and merge at the end. Doing it for adding one new field is like a lot of extra work.
I have a feeling that during our first sprint I lost more that 50 % of my work because some other change rewrote it in repository, which was something I didn’t really expect. And we still fight the whole git process, merging changes again and again as more branches are merge into the main one. It isn’t enough to merge changes when you do the pull request as there might come other pull request before yours and create a conflict again.
I spent about 5 % of my time on requested changes and 95 % fighting the Git.
(unnamed colleague)
It is better sprint to sprint, but still sounds like a lot of extra work considering the fact that we hardly roll-back. And I still don’t care
(read don’t know anything) about all those cherry-picking, revert of commits and so on.
Scratch orgs
At the beginning we didn’t care much about the project file from which new scratch orgs are created. But at the back of my head was that strange scratching – everyone said they spent a long time doing this right, why it was so easy to us?
And it hit us later on, as you might imagine. I still hate the fact that you cannot enable all features in this file (looking at you News and Logos), as you need to think about it, so when you push changes to scratch org and pull back you don’t loose something.
At the same time it was great – for a few hours. We needed to add platform licences and related profiles. Thanks to scratch org it was done in a few minutes, pushed to git repo and our build has been broken immediately for later changes as well. Of course it solved itself later when we got the licences, but you need to think about it.
I still hate to touch profile, as we get the EditReports permission from scratch org, but in our production org it is named CreateCustomizeReports. Seriously Salesforce?
Something similar is with ProfilePasswordPolicy and ProfileSessionSettings files, which you get when creating new profile, you can push it to production for the first time but get errors later on. Time to delete them from repo, which probably isn’t the right way.
holly molly kurwa drát
me, when I found out that because some feature isn’t activated in my scratch org the related elements will be deleted from the component when I’ll push to git
AllowUniversalSearch, enableAccountOwnerReport and a few others are still bitting us.
How should we tackle case-to-emails and similar functionality, which refer to existing users, which doesn’t exist in QA or production org?
We also experience the errors that you loose field level security, luckily it has been solved with the Spring ’19 release.
Non metadata changes
Of course not everything can be transferred via metadata. What I like, as I feel I can „decrypt“ the DX file format, is that you have an idea what won’t be transferred and can do changes manually, while with change sets I never was sure what will and won’t be transferred. I’m pretty sure somewhere is a list of all the things which aren’t transferred via metadata, but who should remember where. (not sure this is the right list)
For example the mobile app branding isn’t transferred via metadata, but the logo (as a file) is. But I cannot chose it when doing the branding again in production, so … should I push it to repo or not, when I have to choose it from local drive anyway?
Is it worth it?
That’s the crucial question.
I like that we are able to find out when something has been changed or deleted, that we can „pack“ (commit) the whole pack of related changed and put description why it has been done. I feel this adds some kind of quality to the whole process.
I like that I can do a lot of changes quickly in text files rather than clicking it slowly in the Salesforce interface. That I can see right in the code who changed it, when and why (thanks to the right extension for Visual Code).
I hate that I don’t know about changes other people do at the same time. For example we had one story to change home page and another to add some design element to home page (they weren’t part of the same story as the second was related to other story where it makes more sense). As we worked on it at the same time I wasn’t aware that my colleague did a change to home page and he didn’t know I wanted to be safe and created a new version of it. And the end my story passed tests (because it had all elements which should be there) and his failed (because the element did’t show up on my homepage which was active by then), while would we know about each other’s work my story would fail (because it had extra element not part of the story) and his would pass. The testing is still strange world to me.
I hate that DX is so slow on our machines, which is something we try to solve with our IT department. But every command I run takes 20+ seconds, so it is really annoying and I try to minimize them as much as possible.
It works greatly with Scratch orgs, with normal instances it still feels like a lot of work to get the metadata (you have to have package.xml file or create a package or name elements you want to get, those names are case sensitive and not related to directory they are saved, so it might be hard to find the proper word). Besides all that I have a great feeling and consider it as a great step towards better implementation.
Updates (look like this post might be updated with new findings)
24. 2. 2019
- one great thing about Salesforce DX – community can extend it. So we solved the problem of wrong permissions (
AllowUniversalSearch, etc.) with plugin from Nicolas Vuillamy - easy way how to install package right when creating Scratch Org is to create a directory installedPackages, where you put one xml file for each package you want to install. The filename is in a format of namespace.installedPackage-meta.xml and its content is following (be careful about versionNumber, that’s the only thing to change)
<?xml version="1.0" encoding="UTF-8"?>
<InstalledPackage xmlns="http://soap.sforce.com/2006/04/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<activateRSS>false</activateRSS>
<versionNumber>1.59.1</versionNumber>
</InstalledPackage>
5. 3. 2019
- Before you change a matching rule, you must deactivate it. – I somehow hoped that the CI would solve all this without touching the org at all 🙁
20. 3. 2019
- looks like it is impossible to push changes to Entitlement processes when they are used (means there is an Entitlement record with link to that Entitlement process, remove the process from the record, not delete the record);
- renaming record type and downloading metadata doesn’t necessary download all of them – we had to change path, quick actions and some profile manually 🙁
9. 4. 2019
- only one dynamic dashboard allowed;
- problems with reports & dashboards sub-folders as they aren’t visible in scratch org, but you can draw the reports/dashboard there manually later on and the dashboard picks up the correct reports;
- when moving reports & dashboards between folders they stay in the old folder as well on your local drive.
9. 5. 2019
- looks like dashboard folder security is always reset after deploy, the same goes with roles/group membership (different IDs);
- every time you download a dashboard and push it to repository you need to think about deleting the running user info, as it is random user who doesn’t exist elsewhere.