A famous thespian, or perhaps it was a Salesforce visionary, once said, “All the world’s an org.”
In the org-based model, your production org is the source of truth for all your code, configuration, and customization.
Even if you have multiple teams working on separate development projects, they develop and release their updates with the same deployment. Everything goes into one package.xml.
Package Development : Instead of building code and customizations for the org, you create a package (a logical set of code). A package is a release artifact that is a group of related code and customizations.
With this new process, you’re able to organize your org into a set of packages.
You store all source for your packages in a source control repository, where the source of truth is maintained.
You build scratch (development) orgs from that source, so you can work specifically on your package.
Package development gives you more flexibility in managing your teams and releases. You can assign teams to own a particular package. Development teams can develop separately and build toward a release of the package, and not a release of updates to the org. With this agile model, you can have more frequent, independent releases, as you can see in the development, build, and deploy flow.
For our enterprise customers, we have a special package type, called unlocked packages (GA), which are especially suited for internal business apps.
The Salesforce DX project reflects this package-based approach to organizing your source.
A Salesforce DX project is a local directory structure of your metadata in source format. It lets you develop and test with Salesforce DX tooling.
It contains configuration files for creating scratch orgs. It can contain data to be loaded into orgs for development or testing. It also contains tests that you rely on to validate your package.
At a minimum, the project manages the source for one package. That being said, if multiple packages get built and released together, you can organize these packages into a single DX project. Each of your packages aligns to a package directory defined in the project configuration file.
After you create a scratch org, you still have some setup tasks to complete. You push all source from the project to the scratch org, set up permissions, and create or load any test data that your package requires.
While the IDE or text editor is available for programmatic (code-based) development, you can use the scratch org for declarative (point-and-click) development. This process is similar to what you do in your sandbox or production org. What’s different in the source-driven model is that you synchronize any development you did in the scratch org with your local project. This synchronization lets you commit changes made in the Setup pages alongside changes made in your local IDE.
A key feature of Salesforce DX is that you can easily keep your project and scratch org in sync. So you can put away those sticky notes! You no longer have to jot down what you changed in your local file system, IDE, or editor, or what you changed in your org.
Salesforce DX tracks any change you make locally in the project and any changes you have made in your scratch org.
Before you push source changes to the scratch org, or pull changes to your local project, you can view a list changes you’ve made. That’s the power of the Salesforce CLI in action.
DX project format breaks down large source files to make them more digestible and easier to manage with a version control system. For example, Salesforce DX transforms custom objects and custom object translations into multiple files and directories. This source structure makes it much easier to find what you want to change or update. Smaller files in source control mean fewer merge conflicts during team development. Say bye-bye to messy merges!
At the start of a project, you can retrieve metadata source from an org and convert it to source format, then store it in a VCS. Once you’ve created and tested your app or customizations, you’re ready to create the deployment artifact. You can convert from source format back to metadata format, and then all your source is ready to deploy to a scratch org. You can deploy all the source, and the deploy operation takes care of updating the files that have changed. You can omit certain files from the deployment, and construct exactly what to deploy by modifying the package.xml file created during the convert process.
Setup -> DevHub -> Enable
enter SFDX into CLI
to authenticate an Devhub org: sfdx force:auth:web:login -d -a DevHub
Adding the -d flag sets this org as the default Dev Hub. Use the -a to set an alias for the org (something catchy like DevHub). An alias is much easier to remember than the unique Dev Hub username.
I configured this earlier & am aware of this on high level but wanted to do this handson Project.
First Step – I created External Data source called OrdersDB using heroku URL provided in trailhead
Using Validate & sync, i synched two external objects Orders & Order Details.
Now on external object Orders, i changed datatype of customerid field from number to Indirect Lookup to account and target value to customerid. (Note: while installing the package, customerid text fied – EXternal + unique got created and values also got populated)
An indirect lookup relationship is a new field type introduced with Salesforce Connect. It links an external object to a standard or custom object in the same way that a regular lookup relationship links standard or custom objects.
Boom, the Account page’s Related List now has Order.
Now on external object OrderDetails, i changed datatype of orderID to External Lookup to order and target value to OrderID
An external lookup relationship is another new field type introduced with Salesforce Connect. This type links an object to an external object.We can link one external object to another external object
Boom, the Order page’s Related List now has orderdetails