3

We currently plan to make the move to pure SFDX and try to come up with a solid strategy to divide our metadata into unlocked packages. The main problem we encountered so far is that we don't know how to properly handle single-file shared metadata, like user profiles.

Putting single-file shared metadata into a separate "base" package might be tricky, in the case of user profiles without having all objects available in that package. Not packaging them essentially means not being able to track them in git. Are we missing something here?

6

One viable alternative is start converting the profiles into permission sets as a part of the DX move .

With permission set you can easily group them with relevant objects .

Salesforce did a blogpost on this and you might find the blog helpful.

https://developer.salesforce.com/blogs/2018/12/migrating-to-permission-sets-for-dx.html

  • Thanks! That would be a way for user profiles I suppose. But what about an object's object-meta.xml file, like Account.object-meta.xml? – Wolfi Jan 25 '19 at 15:00
  • 1
    With DX source format you can break them up and should be no issues .Look into the DX source format for objects. – Mohith Shrivastava Jan 25 '19 at 15:16
  • I'm aware the DX source format splits up an object into a lot of xml files, one for each field for example - which is great. However, for each object there's still at least an unsplittable object-meta xml file, that might have to end up in several packages. Also, objects and profiles were just examples for kinds if meta data we're struggling with. – Wolfi Jan 26 '19 at 14:04
  • The object metadata can be duplicated in your source repo and should do no impact. – Mohith Shrivastava Jan 26 '19 at 14:05
  • But the object-meta could change. How would having duplicates of it have no impact? Just to make sure we're having the same thing in mind, this is what I mean by object-meta xml: github.com/dreamhouseapp/dreamhouse-sfdx/blob/master/force-app/… – Wolfi Jan 26 '19 at 14:35
2

I don't recommend moving EVERYTHING into unlocked packages. Create unlocked packages for individual projects that can stand alone, be tested in a scratch org, and are related to a development team. There is always going to be a sea of unpackaged metadata, many of those standard objects are related to Salesforce CRM functionality. Here is a detailed white paper on this issue...

https://www.metazoa.com/best-practices-breaking-your-org-into-packages/

(I am the CTO of Metazoa, this is a link to our website)

  • I've read this article before. But how would you handle unpackaged metadata then? Not git it...? – Wolfi Feb 1 '19 at 9:24
  • Why put things in Git? I can think of two reasons. One, for backup, compliance, and audit trail. And two, for merging code, and maybe for merging other XML assets. The metadata api does a good job of merging most XML assets, and these are cumbersome to merge by hand. Merging code from developers is a useful thing to do with a repo. So I think the best practice here is to put developer projects into Git and let the metadata api handle other assets. For large orgs, you will have difficulty storing all the metadata in Git anyway... – Bill Appleton Feb 1 '19 at 11:13
1

Currently looking at doing something similar myself - you actually don't need the object.xml in both packages - you can define just the custom fields.

You might have found it hard to deploy becuase sfdx push does not currently correctly merge the object.xml from multiple second-generation packages.

Can see this demonstrated here: https://github.com/JonnyPower/sfdx-push-bug-20190124

I have a case open with salesforce to try and report this as a known issue.

  • Thanks for working on that, it really is an issue. – Wolfi Feb 1 '19 at 9:25

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.