0

I want to have a 1:1 correspondence of the objects in Salesforce and the objects in our Git repo. Furthermore, I want to distinguish in our repo between our code, which has been carefully written line by line, and the 5000 salesforce objects that have been thrown in haphazardly that I cannot delete.

Source tracking is not an option since it doesn't pull and pull the entire list of objects, just the ones that have been changed after the arbitrary point in time that I switched on source tracking. It's opaque about how it selects candidates to be pushed and pulled, and I don't trust it.

Fetch/deploy is not an option because it does not distinguish between objects that are ours and objects that are clutter. Also deploy doesn't delete, which is a bug. Also I can't tell it to fetch all object types, I have to specify all >500 of them manually. No way that's going to be a 100% accurate specification.

With deletions I can't even use an asterisk, which means that I have to manually specify EVERY deleted file in the package.xml.

When making changes via the GUI, even when I do get the right list of objects to be pulled/fetched from my org, some of the settings (like the objectpermissions on the profile) are casually cut out.

How can I make it work normally?

1 Answer 1

2

There is no such thing as a bidirectional "git integration" that simply and transparently mirrors the state of your Salesforce org to and from a Git repository.

The problems you are confronting are well-studied in the Salesforce community, and I'd recommend you take advantage of the wealth of resources that have been developed over the last few years on how to achieve source-based development on Salesforce. There are a number of viable methodologies and the right one will depend on your team, process, and budget.

But broadly, what you need is a comprehensive SDLC based on Git as the source of truth, with deploys happening from your Git repository. Your Git repository should contain only those metadata components you build or customize; there's no need to retrieve the standard objects that you are not customizing. Your goal of a 1:1 correspondence isn't completely infeasible, but it's also not useful.

In that SDLC, you'll need to carefully define where (in which environments) engineers make changes, and a branching structure for how those changes are committed, tested, and moved to production. If you permit changes in Production, you'll need to design a strategy for retrieving and committing those changes as well. Commercial tools may help significantly there if you have this issue.


Source tracking is not an option since it doesn't pull and pull the entire list of objects, just the ones that have been changed after the arbitrary point in time that I switched on source tracking.

Source tracking is a tool that you use during the development process as you make changes. It is not suitable for starting a Git repo. To do that, you'll need to identify all of the components that are in scope and retrieve them. Then, source tracking will support you as you continue development by identifying and retrieving further changes.

With deletions I can't even use an asterisk, which means that I have to manually specify EVERY deleted file in the package.xml.

You should use automation to construct your destructive changes deployments. CumulusCI (my team's FOSS product) can do this, but so can other community SFDX plugins and commercial options.

In any case, this is closer to a feature not a bug. Using wildcards to perform component deletions is something that is rarely needed in a development process and rather dangerous.

When making changes via the GUI, even when I do get the right list of objects to be pulled/fetched from my org, some of the settings (like the objectpermissions on the profile) are casually cut out.

Managing Profiles in source control is challenging. The Metadata API behavior is discussed in the documentation. Third-party plugins like SFPowerKit include additional tools that may make this process less painful for you.

1
  • 2
    Your goal of a 1:1 correspondence isn't completely infeasible, but it's also not useful - yessir. This Q is an XY problem. 1:1 correspondence is a possible solution to some unstated goal regarding quality of SDLC.
    – identigral
    Jun 2, 2022 at 15:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .