search

forcedotcom / devops-center-feedback

61 stars 2 forks source link

Are there any best practices around what metadata to manage in DevOps Center (and thus GitHub)? #213

Open matthewpomar opened 2 years ago

matthewpomar commented 2 years ago

Hi,

I'm working to backfill our GitHub repo with metadata but need to decide what metadata to include. I'm of the mind that everything that can be managed via SFDX retrieve/deploy should be included. However, I'm not certain if taking this approach will cause issues, either from a technical or practical perspective.

Does anyone from the DevOps Center team have any best practices on what metadata to include in the DevOps Center tool (and GitHub) and possible even a package.xml template file?

If not, has anyone in this community found a set of metadata that work best for them and would kindly share their package.xml file?

Thank you.

RupertBarrow commented 2 years ago

Hi Matthew, The idea is to manage everything you need in Github repositorty metadata, so, at the end of the day, you will need "all the metadata". IN real life, if you are trying to upload metadata to Github from a large soup of metadata from your org, you should first think : "how should I package my stuff ?", i.e. how should I break it down into pieces.

The easiest way to go is to create an SFDX 2GP (second-generation) Unlocked org-dependent package : put your metadata progressively into this package, each time you make a change to something else. Progressively, you will populate this package, but the rest of the metadata will stay in your production and sandboxes.

On the other hand, if you are creating a new app or feature, you should put all that metadata into the Github repo, ideally (but not necessarily) packaged into a different package.

Finally, I can give you a quick answer to your first question : sfdx force:source:manifest:create --fromorgwill create a package.xml file with "everything" which was in your production org. BUT, this might be a bit too much for you. Start with : Objects, Classes, LWC and Aura components, tabs, applications, permission sets and other related stuff like record types, picklist values etc. Use the Salesforce Metadata Coverage Report to look these up and find their names to add to package.xml.

jdgirald commented 2 years ago

@matthewpomar from experience with multiple projects, this is what we currently have in our github repo "ApexClass", "ApexComponent", "ApexPage", "ApexTrigger", "AuraDefinitionBundle", "BusinessProcess", "CustomField", "CustomLabels", "CustomLabel", "CustomMetadata", "CustomNotificationType", "CustomObject", "CustomPermission", "CustomTab", "DuplicateRule", "FlexiPage", "Flow", "GlobalValueSet", "Group", "Layout", "LightningComponentBundle", "LightningMessageChannel", "ListView", "MatchingRules", "MutingPermissionSet", "PermissionSet", "PermissionSetGroup", "Queue", "QuickAction", "RecordType", "StandardValueSet", "StaticResource", "ValidationRule", "WorkflowAlert", "WorkflowFieldUpdate", "WorkflowOutboundMessage", "WorkflowRule", "WorkflowTask"

msteinersalesforce commented 7 months ago

This video suggests not seeding anything and only tracking CHANGES in GitHub. To me that means the prod org is still the source of truth vs GitHub. (Until changes to prod are locked down AND all changes are made deployable this will unfortunately always be the case).

I typically use Visual Studio Code's package generator, select all and copy prod as a starting point.