3

So, with the move to DX and the source format we can and probably should version much more than we previously did with the metadata format. Objects obviously are a pretty obvious and mandatory choice if you want to use scratch orgs at all. But I wonder - are they any parts of an org that should not be versioned? Parts that are so org-specific (to this very instance) that it causes more problems to version it than it actually solves? Are they any "what goes into versioning" best practices? What do you version? And what not?

7

There may be some best practices but how you use them applies to your situation (org/team) and how you deploy from your source control. In terms of documentation - I do see some limitations of DX by Salesforce and this whitepaper by Gearset about adopting DX.

Below is just some things we learned along the way


Understand your team's comfort level and have a workflow for each

  • How will admins move their changes?
  • How will developers move their changes?
  • Making sure every one on the team is on the same process/page and is able to do it.

Analyze your previous deployments to understand what metadata you're deploying

  • I find this useful because every team is different. You may find you've only deployed 10-12 different types in last x months. Think of it like the 80/20 rule, any chance you get to keep your source small can help depending on org size.
  • You can always add new metadata types as you go if you do find you need to include them.
  • The goal is to version what you're changing

Come up with Goals/Pain Points and identify how your process will meet those needs

  • Nothing worse than adopting something like this and then realizing you missed the mark on what you were hoping it would help with.
  • How can you handle disaster recovery, avoid work collision, etc. This depends on what is troubling you now and is different for each team with different strengths.

I would not include anything that you do not control, edit, or release entirely within your team. Some examples below that you may choose to not include fully (but can still add as needed for deployments that you're creating/modifying)

  • Reports
  • Dashboards
  • Email Templates
  • Groups
  • Queues (lists users that are members which may change by end users)
  • List Views

Understand how the Profile metadata works. This will be the trickiest part to manage.

  • You only get what you pull it with. So make sure you understand the dependent components you need to always pull to get it.
  • Layout assignments = Layouts + Profile
  • Object permissions = Object + Profile
  • etc
  • Might be good reason to look at utilizing Permission Sets more as they're easier to manage

Try not to include installed package metadata, but do include the installed package metadata type

  • Just include the metadata that stores the package version installed which will control all the dependent metadata.
  • Again, goes back to trying to only version what you release/control/change.

If you're using scratch orgs, confirm you're able to push your source successfully before relying on it in your process.

  • With org shape in beta, this may become easier as the hardest part was getting the right features activated to support your source
  • This is one area that I find requires the most troubleshooting and learning (if you use them).
  • This was the most thorough answer I ever got for such a seemingly easy question that obviously covers a very very complex topic. There's so much good stuff in there that all the people involved with this project will benefit from, so - thank you very much for this incredibly detailed explanation! I hope this is as much help to others as it is for me. – Semmel Oct 2 '20 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.