The metadata api source structure has its limitation but it is stable given it is part of metadata API specs, which guarantees full backward compatibility for at least 3 years. That means you can set up build script, CI and everything once without worrying that it will break, at least for a good period of time.

On the other hands, Salesforce DX changes are released every week. How do I ensure my CI scripts and everything is stable. What if it breaks next week ? What if guys at Salesforce decide to change the convention and introduce changes, for instance, all aura components should be placed in a folder named 'aura2' instead of 'aura'.

This is part of the reason I didn't like to rely on the CLI for integration and prefer using API instead. Based on what I've seen, it's awfully unstable.

Take this as an example, CLI update caused force:source:push to spike CPU to 67%: https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/751/high-cpu-usage-on-source-push

Even the format of the sfdx-project.json & scratch org config files are changing occasionally. I am not opposed to changes but what is the end user agreement for backward compatibility using the CLI ? I couldn't find it anywhere.

I'm aware that the CLI has version and it is also auto updated. But We need to understand the full impacts of specs changes too frequently.

1 Answer 1


You can peg your continuous integration solution to a specific SFDX version so that you don't have to worry about unexpected changes modifying the CI pathway.

For example, on CircleCI, you can do something like

    - restore_cache:
            - sfdx-6.8.2-local
    - run:
        name: Install Salesforce DX
        command: |
            if [ ! -d node_modules/sfdx-cli ]; then
                export SFDX_AUTOUPDATE_DISABLE=true
                export SFDX_USE_GENERIC_UNIX_KEYCHAIN=true
                export SFDX_DOMAIN_RETRY=300
                npm install [email protected]
                node_modules/sfdx-cli/bin/run --version
                node_modules/sfdx-cli/bin/run plugins --core
    - save_cache:
        key: sfdx-6.8.2-local
          - node_modules

to fix your solution on Salesforce DX 6.8.2, much as you might build a solution against a specific versioned API.

If you do not take such steps, you are correct that (versioned) changes may cause alterations to your CI solution.

  • Thanks David. I kind of knew about this approach. But what if you have 10 devs in your team. Devs typically set auto-update loccally and might check in files that are not compatible with the CI process since it's on an older version. What do u do ? Do u ask all ur devs to disable auto-update locally too ? They might not like it since they will stay behind. Sep 9, 2018 at 21:42
  • Respectfully, I think you're way overestimating the pace of breaking changes that affect the source format that devs will be pushing. Even if that did happen, it'll just break the build like any other bug, and should be stopped before it gets merged into your integration branch.
    – David Reed
    Sep 9, 2018 at 21:49
  • Changes that affect the command-line parameters of SFDX aren't uncommon, but I really don't think you need to worry this much about regular SFDX releases making major backwards-incompatible source format changes unless you are proactively using new functionality that didn't exist in prior versions.
    – David Reed
    Sep 9, 2018 at 21:50
  • Call me pessimistic perhaps but I don't overestimate anything. I check everything BEFORE I use it. DX came way below the standard for me at this point. It didn't take much time to see how fragile it is. This one for example: salesforce.stackexchange.com/questions/195695/… What is your suggestion, have the dev on auto-update or ask them to fix on a version locally and disable update ? Sep 9, 2018 at 21:56
  • 1
    I would, personally, disable auto-update on CI and use a fixed version, and allow the developers to decide for themselves. I do understand where you're coming from, I just don't see the level of risk that you do there, and I think the use of CI mitigates that risk in the developers' individual toolchains. If you're not comfortable with it, though, you can lock it down to a fixed version everywhere.
    – David Reed
    Sep 9, 2018 at 23:21

You must log in to answer this question.

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