5

I am setting up a CI process using GitLab and SFDX. Developers do their work in a scratch org, then commit their changes to a QA branch. Upon this commit, the CI pipeline then deploys the entire source (force-app/) to a QA sandbox. We are not currently using unlocked packages.

Instead of deploying the entire source each time, how would it be possible to only deploy the files changed in the latest commit?

I'm thinking something along the lines of using the git diff-tree command to build a list of the changed files, moving these files to a separate directory, using this directory in the sfdx force:source:deploy command, and then deleting the directory. But how to pull this off through a CI pipline, I'm stumped.

Improve this question
6
  • 6
    I've worked on taking the output of git diff to feed a bash script to generate a package.xml to feed into SFDX, but in the end this really isn't how SFDX is meant to be used. Do you have your org broken up into different projects (not necessarily unlocked packages), or is it just one monolithic project? If you do have separate, smaller projects, I don't think that worrying about deploying just the deltas would be worth it. Getting a reasonably accurate answer on this one means you'll probably need to tell us more about your CI system (do you get a shell, or can you run arbitrary scripts?) – Derek F Apr 14 '20 at 19:43
  • 3
    Unless you are hitting a limit (10k components per deployment, for example) it is likely to be way more work than it's worth, and not guaranteed to work the way you expect it to. The route you outlined is fundamentally how one does it. I've done it on GitLab CI with a different deployment tool. – David Reed♦ Apr 14 '20 at 19:59
  • 3
    I'll chime in, too. Yes, you should be using unlocked packages. They offer best deployment performance and also does automatic delta calculation on install. That's the way it's meant to be. – sfdcfox Apr 14 '20 at 20:04
  • 2
    Why not use force:source:push to do the delta deployment? I'm assuming your CI process will have the .sfdx folder maintained between invocations (if it doesn't this won't work). – Phil W Apr 14 '20 at 20:11
  • 4
    By the way, personally I think this is the wrong approach for QA; the QA org will accumulate cruft over time that isn't part of your git "source of truth". Better to have QA also done on a scratch org, so you know it is clean. You could consider data loader or an SFDX CLI command to import QA's data set into the org. This is what we've adopted (albeit with a custom SFDX plugin to let us do funky stuff like time shift our data which is date/time based). – Phil W Apr 14 '20 at 20:15
2

Check this: https://www.npmjs.com/package/sfdx-git-delta

It doesn't move files into a temp dir it instead generates a package.xml referencing only the delta between 2 commits that you can use to deploy only what changed (sfdx force:source:deploy -x ./path to package/package.xml). It seems to be working well, at least on the few tests I did.

Improve this answer

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.