2. #YD19
A bit about us
Martin Humpolec
Salesforce Consultant
Salesforce MVP
Lightning Champion
Trailhead & Certification Addict
Prague Salesforce User Group Leader
CzechDreamin conference organizer
Blogger: MartinHumpolec.cz
Twitter: @mhumpolec
3. #YD19
A bit about us
Adam Sienkiewicz
Salesforce Consultant
Trailblazer & 7 times Salesforce
Certified
Salesforce Enthusiast
Data Analysis Fan
4. #YD19
Table of content
• What is DX
• Why do we use DX
• Pros / Cons summary
• Use case – our process flow overview
5. #YD19
What is Salesforce DX
Salesforce DX is a Salesforce product in the App cloud that allows users to
develop and manage Salesforce apps throughout the entire platform in a
more direct and efficient way.
NOT for developers only
NOT an “all or nothing” option
6. #YD19
DX Learning Curve
I spent about 5 % of my time on requested changes and 95 % fighting the
Git.
@StudiosViloria
10. #YD19
Salesforce DX = VCS (for us)
DX is actually just a small part of that picture, but people will blame it for
everything.
11. #YD19
Why do we use DX?
• Provide better performance with version control, disaster tracking and
auditing
• Integrated with popular IDE tools
• Ability to migrate from standard metadata schemes
• Streamlined release management
• Artifact-based programming concept is easier to implement
• Easy packaging and deployments
• Price – it is free!
12. #YD19
Salesforce DX in practice – Why did we chose DX?
• Will to learn and train the team about new paradigm
• High number of dev team members
• We wanted to give control to the team over their orgs
• Because nowadays DX is hip (?)
13. #YD19
Pros
• Accelerates development knowledge gathering
• Ability to copy things/update the xml
• Scratch orgs to test things
• The ability to extend it with your own/community code
• Once you know the basics it is easy to progress
14. #YD19
Manual or click?
Manual changes – How to learn patience and understand that in the end
the SF platform is just a set of <> lines with true/false values
16. #YD19
Cons
• “Disconnection” between people as everyone works in their instance
(“weird, mine works fine”)
• Some things aren’t possible to set via metadata when creating scratch
org (should be changed by summer release)
• Some things are hard/impossible to push through (entitlements, security
settings, …)
• Some errors are difficult to investigate due to relatively new concept
without complete documentation and user cases
• A bit complex in the beginning
17. #YD19
Salesforce DX in practice – Initial Challenges
• Lack of structure in terms of scratch org setup, no config, no features
defined, no processes, no ownership
• Problems with deployment
• General lack of knowledge about the tool within the team. Quickly turning
into large knowledge gap between experienced devs and beginners
18. #YD19
Salesforce DX in practice – Initial Challenges – Solution Approach
Introduce release/deployment manager full-time role
RESPONSIBILITIES:
Setup config for
scratch orgs Create and refresh
sandboxes
Run deployments
Support the Team
Define and build
deployment flow
Configure
Continuous
Integration
19. #YD19
Salesforce DX in practice – Challenges along the way
• Some features need to be a manual pre-deployment step for scratch
org
• Scratch org is not retrieving full config for profiles
• Manual hotfixes on “release train” orgs led to lack of single source of
truth for configuration
• Overwriting changes in git, confusion about the flow
20. #YD19
Salesforce DX in practice – Challenges along the way – Solutions
Rule no. 1 – „You always make changes to profiles manually!”
Rule no. 2 – Rule no. 1 cannot be omitted
In the end challenges happened to be a great catalyst for learning new
things!
23. #YD19
What we can confirm
The problem is that no matter how much you say that source control is the
ultimate source of truth, if people can make changes on the org directly, the
org ultimately represents the true picture of what’s going on.
(https://bluecanvas.io/blog/2019-2-5-why-salesforce-dx-and-git-flow-dont-work-for-salesforce-teams)
24. #YD19
Salesforce DX in practice - Team adoption
• Most of the non-technical team members initially started on the very high
left end of the rectangle, gradually moving towards center
• Lot of complaints about git usage
• Experienced users were unhappy
having to support others apart from
their tasks
25. #YD19
Git flow
On average day we know Git well and can use those 4 commands. And
then there is that exception.
28. #YD19
Good practices
• Use properly configured scratch orgs
• Proper description in commits && their clever use
• Have a set of sample data
• Use .forceignore wisely and don’t be afraid of it
• Code retrieve-convert speeds-up hotfixing and deployments
• Naming conventions