6

We recently decided to migrate our org to SFDX so I decided to document myself as much as I could. The thing is when reading the trailheads I found the following assertion:

Do you have distinct teams that build and maintain these applications? If so, you can isolate those applications into their own artifacts.

Is there a way to explicitly create artifacts or is it just an abstract concept? Does it refer to packages somehow? Mainly I'm wondering if Salesforce just tries to explain how DX works behind the scenes or he actually has a way for us to seggregate our org in small modules.

Cheers!

9

I'm trying to manage my own org's migration to SalesforceDX, and I'll say that the terminology that Salesforce uses is a bit too vague for my tastes (and not entirely consistent).

An 'artifact' is just an abstract concept that seems to be used to refer to both individual components (Apex Classes, Workflow, Validation Rules, SObject fields, Visualforce pages, etc...) as well as a collection of components (say, a Visualforce page, along with its controller extension class, static resources, an SObject field that only it uses, and a permission set). The definition seems to change between different sources (say, the SFDX module and the SFDX webinar).

After wrestling with the inconsistent terminology, here's my understanding...

  • Individual metadata/code (a field on an SObject, a List View, an Apex class, a Tab, a Page Layout, etc...) are Components
  • One or more components create the abstract unit called an Artifact. Any single component can exist, at most, in only one Artifact. App Exchange apps are an example of an Artifact. My org contains code to generate Gantt Charts using d3.js. The d3.js source (as a static resource), a Visualforce Component, a pair of controllers (and test classes for them), and a pair of Visualforce pages that use my component (so I can include the chart in page layouts) comprise my Artifact.
  • An Artifact should be (ideally) completely independent. If you deploy an Artifact to a scratch org, you should be able to run the unit tests included with that Artifact, and they should pass.
  • A Project is something that exists on your local computer(s). It can contain multiple Artifacts. A Project is the intermediary between version control (source form), and Salesforce proper (metadata api form).

Unless you plan to offer your Artifact on the App Exchange (either as a managed, or an unmanaged package), then packages in Salesforce don't play that much of a role in SFDX at this time. Building an unmanaged package is just one way to get specific pieces of metadata/code from an org into an SFDX project. Once you have it in SFDX, the idea is that you'd push things into version control. At that point, the unmanaged package has served its use, and should be discarded. The unmanaged package won't help you deploy code between orgs.

Components that are used by multiple Artifacts don't really fit well in the current SFDX model. I'm not sure if SFDX absolutely can't deal with having one Component appear in multiple Artifacts, but it's not a good idea to do that even if we can (how would changes to the Component in one Artifact affect the same Component in another? How would we choose which version to use? Could choosing one over another even be done automatically in a reliable manner?).

For Components that would reside in multiple Artifacts (SObjects, Validation Rules, Fields, etc.. will be common targets for this distinction), we need to put them in a completely separate Artifact. At that point, we start having dependencies between Artifacts.

At this time, Salesforce does not have a good solution for managing dependencies. If you have one Artifact (artifact b) that depends on another (artifact a), you'll need to manually deploy Artifact A to your scratch org, sandbox, or production before you deploy Artifact B.

Salesforce is currently working on improving the way packages work (Packages 2.0), and the hope is that the new version of Salesforce packaging will address issues with dependencies between Artifacts. It's currently in beta, as of Winter '18 (API v41.0), and about the most information you'll find about it at this time is through the Packaging 2 Salesforce Success Community Chatter Group

1
  • That helped a lot, Derek! Thanks a lot for your elaborate answer :) Nov 6 '17 at 15:46
1

Breaking your application into multiple packages or modules is possible by figuring out dependencies you have among your team's .

If you have different teams and they have code base that's not shared across teams it's just easier to assume a scratch org model for each of your team .

If you have one gigantic package without proper boundaries , you will have to figure way to logically split the package into multiple packages .This is an abstract concept as you figured .In most scenario the spearation can be based on functional units or depending on different teams .Note Here packages can be bunch of unmanaged code and components.

Shared metadata can be part of both the packages or modules. You will resolve them finally when teams give you the metadata .Scratch org definitions can be converted back to metadata api format using the convert command .so you will eventually merge all .

Use a git dedicated branch to do the merges and resolve conflicts.Do frequent merges to avoid looking at larger chunk of the code.

2
  • So at the end of the day, I just need to create different unmanaged packages for each "module"? And what about the shared metadata, like, for example, the contact object? Nov 6 '17 at 9:49
  • Shared metadata can be part of both the packages or modules. You will resolve them finally when teams give you the metadata .Scratch org definitions can be converted back to metadata api format using the convert command .so you will eventually merge all .Hope that makes sense Nov 6 '17 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.