Migrating to Salesforce DX

Question

We are looking to move and migrate to Salesforce DX, and I've been playing around with the cli / tools and following the steps provided in the developer guide.

We have a few managed packages, along with some custom apps being built in our dev org. I have created an unmanaged package using the package manager and added the App, which inherently added all of the dependencies (custom objects, fields, Lightning Components, Visualforce pages, etc).

I've been having a hard time pushing the retrieved metadata source to my scratch org. When I run the command I get tons of errors most of which seem inaccurate:

• Class not existing (even though it does exist)
• Variable does not exist
• In field: field - no CustomField named
• Apex class 'Name of Class' does not exist
• We couldn't validate your component. Review it and try again. The following code has invalid references which caused safe validation failure. AuraDefinition [id:null deftype:null format:null source:null] (0:0)

Among many others. I've searched around extensively and it seems I must fix each of these issues, however some of them just don't really make sense as to what exactly the issue is.

Is this due to lack of data, and the code not properly handling such conditions. Or is it because the source push is not doing it in the right order?

I would just like some guidance or insight as to what steps I must take to be able to replicate a component, module or app into the scratch org, keeping in mind that there are a lot of dependencies. Why is this happening and what must I do to resolve it? Hopefully this was clear, thank you.

Answer 1

Migration using SFDX is faster then the normal change set approach but we need to handle the dependency part as well. You need to manually check for all the dependency in your code and make sure you have added all components.

I have also faced this issue and here are the steps which I have followed to do this process bit quickly.

1. If you are moving package component I suggest you add the namespace in your project project-scratch-def.Json file

   "namespace": "MyNamespace",

2. Second I suggest you to create your own package.xml to fetch all the metadata using SFDX

Retrieve Unpackaged Source Defined in a package.xml File

You can first fetch the existing package and then use that package.xml file to fetch the updated component. You can add or remove component reference here and make sure don't add any unnecessary components.

3. If you have done modification on standard field you need to refer them using StandardValueSet in your xml file.

<types> <members>AccountType</members> <!-- and so on... --> <name>StandardValueSet</name> </types>

4. Now check your error message they might giving you some dependency error on some object or may be page layout. The best bet is manually go to those component XML file and remove the reference. It will not take much time.

After follow above steps try to deploy it again into scratch org and you will get success. If you need to enable few extra feature you can do them as well. Take reference from here:

Scratch Org Definition Configuration Values

Answer 2

Almost all of these errors are caused by a single point of failure, such as a component failing to deploy because of a class failing to deploy because an object failed to deploy because a field failed to deploy. Fixing it usually requires fixing the base failure. Unfortunately, some subtle bugs exist in DX, so you may need to end up pushing in pieces. I'm trying to work through this in our org, which has nearly 10,000 artifacts to deploy to a scratch org, and it's pretty painful. For now, you might need to prepare multiple artifacts that you install in phases, such as bare-minimum objects, followed by an artifact with all non-formula fields, followed by formula fields, etc. Hopefully they'll get most of this ironed out in a release or two, but for now, fixes are pretty manual and usually involve breaking up major parts of your metadata into more manageable chunks.

Answer 3

Migrating to DX, I take to mean two different things.

1. Adopting the Salesforce CLI tool
2. Moving your development process to make use of the new metadata structure and workflow made possible by scratch orgs.

The first can be done, before diving in with both feet into the second.

For number 1, there are some really useful productivity features in the Salesforce CLI that you can make use of immediately that work on any org (not just scratch orgs). Things like deploying test data sets, accessing log files, authorization, testing, executing anonymous Apex code remotely. To dip you toe in the water

For number 2, Most development teams will need to begin the work of rationalizing code and metadata dependencies before diving in and successfully moving their developer workflow to DX. The Architecting Unlocked Packages session at TrailheaDX 18 proposed the best explanation I've seen of an architectural pattern for organizing the development artifact (code, metadata, settings) dependencies in an org to make use of next generation packaging.

We also announced a dependency checking pilot for Summer 18 in the Salesforce DX keynote at TrailheaDX 18 with a new Dependency API. Check out the video to see what is coming. It gives examples of running a tooling API SOQL query to view all code and metadata references of a given item. There's also a second query example of all items that reference a given bit of metadata or code.

Definitely reach out to your AE or success manager if you want to get into the pilot.