4

Is there a way to create scratch orgs that have the same metadata and schema as the production org?

While using Salesforce DX to develop components like Page Layouts, it becomes instantly clear that a baseline scratch org won't work all that well since they do not include layout customizations and added/removed fields.

If one cannot create a scratch org mimicking the production org, how does one make sure that components, such as Page Layouts, don't overwrite existing customizations?

Recently Salesforce added a feature to allow one to create sandboxes from other org. For example, one can now create a dev sandbox from production or another dev sandbox. It would seem that it should now be possible to create a scratch org from another org by providing an orgID so that one doesn't start with an empty shell.

Improve this question

2 Answers 2

Reset to default
5

You can deploy page layouts and other types of metadata to a scratch org, so that it will mirror production. DX is intended to be used for all of your Salesforce metadata management needs, including mere customization settings like page layouts, custom buttons and links, list views, and more. Much like the Force.com IDE, you'll find that almost all customization that you can do in Production you can also do in a Scratch org. There's a few limitations, obviously, but they should be far and few between.

Ideally, in a truly managed org, all customization should be vetted through development and QA first. Where I am employed, we keep everything in our repo, including profiles, page layouts, and user roles. Changes to page layouts are implemented by developers, committed to the repo, and then pushed to production overnight (currently a manual process, but eventually we'll get to using Continuous Integration). Keeping your customization inside a repo allows you to recover from accidental changes or rolling back a bad customization.

Using a repo means that you should never be modifying production directly. If it's not in your repo, it does not exist. Of course, there are tools like AutoRABIT and so on that can help ease the headaches of ignoring this advice, but if you strictly work with the assumption that your repo is the source of truth, you'll avoid overwriting customization done in production, which makes it easier for developers to spin up accurate scratch orgs, and reduces the odds that you'll overwrite customizations.

Improve this answer
2
  • 1
    Thanks. I agree with this, however my client doesn't have VCS and probably won't, unless I can convenience them otherwise. Knowing this, how do I copy all the page layouts/dependent fields/validations/etc. so that I can simply add a new field to an existing layout? Seems silly to bring down dozens of dependent components to deploy one field using SFDX. Perhaps I'm still missing something.
    – Swisher Sweet
    Commented Dec 27, 2017 at 23:58
  • 2
    @SwisherSweet DX works best when you have a Source of Truth. If you don't, you may as well be using sandboxes and change sets. Scratch orgs are created from a source. You can use DX Packaging to create subsets of configurations and deploy them independently, if that helps, but you're still going to have to pull down all the dependencies you need. If they're not going to go this route, you may as well stay with sandboxes and change sets, or whatever mechanism you use today. DX isn't for everyone, to be sure.
    – sfdcfox ♦
    Commented Dec 28, 2017 at 4:07
3

See here: How do we create a scratch org with sandbox environment?

There's a feature in pilot that will allow you to specify a sourceOrg parameter when defining scratch orgs. This is not GA yet and I'm not sure the timeline for it. It was demoed at Dreamforce and that's the first I heard of it.

Unfortunately DX is just not well-suited right now for a use case where admins are making changes in prod and (they or their managers) can't be convinced to be brought into the DX workflow - especially if you're a dev consulting for a client org. It seems that SFDC is putting some thought into this but it's not fully figured out yet. In the meantime if you want to deploy something using DX that has big dependencies on the shape of prod, then yes, you have to pull all the metadata dependencies out of prod into VCS so you can have them in your scratch orgs.

Improve this answer
1
  • Do you know if this feature has been released yet since we can now created sandboxes from other source orgs?
    – Swisher Sweet
    Commented Aug 14, 2018 at 16:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .