#DX Packaging0 人正在讨论

It can always be a daunting task to take an existing Unpackaged metadata and migrate it to DX. Well, not anymore...

Use the power of Graph Databases to carve out package boundaries, for your unpackaged metadata.

You don't need to be an expert in Graph Databases. The following npm package takes care of exporting metadata dependencies in a format that can be directly imported into Neo4J, a popular Graph Database.

https://www.npmjs.com/package/sf-dep-graph

Watch how easy it is to take a sample application, and migrate it to DX, using a simple iterative approach:

https://youtu.be/O5UsiJPFPzs

#Salesforce Platform #Salesforce Developer #Unlocked Packages #DX Packaging

ISV package objects fields are used in custom code base apex classes. To create a unlocked package with apex classes fields which are part of ISV package need to be added to the packaging model. How to add these to DX packaging model?    #DX Packaging #DX Guide #DX Developer Git Deployment

We are having trouble upgrading values of a picklist field of a custom object using packaging, Whatever values get installed during the first time stays and no further changes to the value are picked up.

Any ideas on whats the process for upgrading values of picklist fields through packaging?

Hi

We recently did our first deployment to prod and realised that all the custom profiles were somehow given access to our new objects and app in the package. The package only has permission set meta data nothing to do with profiles. Can anyone explain how this could have happened please?

appreciate some help

Newbie alert.

I have to start working on converting my existing ultimate edition Salesforce Org to a DX project. The issue we have been trying to address is around Namespace. If we have to convert all our existing code in to separate unmanaged packages, would it require to change everything to have namespace and do a complete overhaul of every apex class, trigger, etc? 

any pointers to any such documentation?

I am working with an org that has 40,000 lines of "beautiful soup" (unpackaged custom apex). I'm ready to move my first bits of code (which have no dependencies) to unlocked packages. If I understand correctly, the best practice is to manage one unlocked package as one github repo. If that's true, ultimately my org will be represented by many github repos. How do we organize this set of repos? I don't think that Github has the concept of a bundle or set of repos that go together.

Has anyone tried to promote a second generation (unlocked) package to released yet? I just tried it for the first time today and I am getting the error message:

INSUFFICIENT_ACCESS_OR_READONLY: You don't have the correct user perm to promote a package version to released. Ask your Salesforce admin for help

Does anyone know what I need to change in my user setup to allow this? I'm already in the System Administrator profile and I am able to create scratch orgs, version packages etc.

@Dileep Burki

Hi Guys, I am wondering if anyone has solved for the issue I am seeing. We have 3 potential packages, these all use the case functionality. The challenge we have is that each module requires the use of a case assignment rule. Within Salesforce we can only have one active assignment rule at a time which means we would need to merge the rules into one, which of course will cause a dependency between all three modules. Has anyone come across a fix for this or any suggestion as to how to solve?

Thanks