1

New to DX and I faced the following issue:

In my Prod environment I have set of custom objects & custom fields. When I create scratch Org I would I like this Org to have all these fields, so the package I'm developing could use them. I don't want to create all these fields one-by-one

How can I achieve this?

| improve this question | | | | |
0

The goal of DX is to enable Source-Driven Development, and that you should start with setting up a source code repository in DX format if you are going towards DX. There's no direct way to setup up a Scratch Org with metadata from a different Org.

With a source code repository, it means that you will have all the objects/fields stored in the repository somewhere which is in your Production. And then when you create a Scratch Org, you push those components from the repository to your Scratch Org. This way you don't have to create the components individually but rather utilize the source-driven approach.

If you don't have a repository setup yet in DX format, then you will need to utilize Metadata API to be able to retrieve the components from Production, convert it to DX format and deploy it in your Scratch Org. You can find more details on the documentation Migrate or Import Existing Source.

| improve this answer | | | | |
  • The objects/fields stored in the repository may not yet be in production. The repository will at times be the same as production, though most of the time will be ahead of production with changes for new features etc. I know a lot of folks view Production as the "source of truth" for an implementation, but this is (to me) wrong. You can't properly control changes in Production and it is difficult to roll back changes that should not have been made. I view the "repository" as the "source of truth". This should be held in a Version Control System such as git. – Phil W May 2 '19 at 17:34
  • @PhilW I agree with you on the "source of truth" that it should not be Prod. It should always be the source repo even in a traditional development model. Usually the way I see it is to keep the "master" branch in sync with Prod and then utilize feature branches for specific releases. And once you deploy in Prod, merge the feature to master. – Jayant Das May 2 '19 at 17:59

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.