Salesforcedx-vscode: Deploy On Save Performance Update

[ntotten]

The current implementation of deploy on save relies on watching files for changes and pushing changes no more than once every 4.5 seconds.

Problem

This implementation results in a number of undesirable behaviors:

1. Multiple deployments can be triggered at the same time. If two files are saved say 5 seconds apart, but the first deployment takes longer than 5 seconds a second deployment will be triggered while the other is still running.
2. If many files are saved quickly, each one is deployed separately (when using source:deploy). This results in many extra API requests that add extra overhead.
3. Even in the case where a deployment is quick (say 1 second), if I save a file, then that deploy is triggered, and then quickly save another file, the second file won't start deploying until 4.5 seconds have elapsed from the first save - resulting in an unnecessary deploy.

Desired Behavior

This implementation can be dramatically improved to result in the following behaviors:

1. When a deployment is currently running, no new deployments should be started.
2. When files are saved while a deployment is running they should be queued for a future deployment.
3. As soon as one deployment finishes a new deployment should be started.
4. When a deployment is started, it should contain any files that are queued so that the number of deployments are minimized.
5. If there is no active deployment, and no files in the deployment queue, any file save should trigger an immediate deployment.

[melissajhansen]

Yes!!!! That 4.5 second delay has been a real killer. I could understand a delay if it was auto-saving, but when I'm hitting cmd-S it's because I'm ready to save/compile NOW. This sounds great!

[rapsacnz]

Yes, great idea. I can see the rationale behind the delay, but it's very simplistic. All your points are good ones!

[ChuckJonas]

Sounds solid to me.

Another really "Nice To Have":

• If metadata fails to deploy, it will be included in any subsequent deployments until that metadata succeeds

This would be really helpful when trying to save metadata dependencies on each other.

For this to work:

1: rollbackOnError would need to be false
2: There would need to be some command/way to clear the queue.

[jimwaz]

I really like that the feature exists! Thanks.

1. The delay is tough, I am never confident if it will deploy since it feels like a long time. On save I’m ready for it to deploy. Maybe take a page from mavens mate, I never had a issue there.
2. Can the response include more friendly messaging, successful deploys recieve a successful message, looking for code 0 isn’t intuitive when your new. Also, can the error messages be broken out, it’s embedded in the middle of the response. I can usually fix the error faster than I can find what the error was. Mavens was good at this as well.

[brpowell]

Hi @jimwaz. To address your second point, If you're using the latest version of the extensions deploy results are now shown in both the VSCode problem view as well as the output view. You'll see the results as a human readable table and successes are included. Addressed in #1085.

[jimwaz]

Hi @jimwaz. To address your second point, If you're using the latest version of the extensions deploy results are now shown in both the VSCode problem view as well as the output view. You'll see the results as a human readable table and successes are included. Addressed in #1085.

@brpowell I updated my CLI and I now see the errors listed out! that works great!

[smrobert09]

@ntotten What if a different approach to this was taken?

In source based development, the cli uses 'sourcePathInfos.json' with modstamps/file hashes to determine what has changed since the last push. The file is built when you do a force:source:retreive, but is immediately deleted.

Wouldn't it make sense to leave the file intact and use it to detect all changes needing to be pushed.
IF BOUND TO SAVE: Decrease the time to <1 sec (to allow for saving multiple files/save all open files). Then pick up all changed resources and push.

IF ONLY BOUND TO A 'COMPILE' KEY BINDING: User hits a 'Deploy all changes to org' and executes the same process.

[ChuckJonas]

In the meantime... how bout making this 4.5s delay configurable? Development is absolutely unbearable with it in place

[ntotten]

So the problem with changing the delay (and making a setting) is that we actually released this tool initially without the delay and found through telemetry that for many uses this resulted in a massive queue of deployments and caused perf issues. We don't plan on adding a setting for it, but we are planning on fixing this soon. For now, you can change this yourself if you want to be really brave by simply editing the file in the extensions install folder. You'll have to do it every update, but you can also write a simple script to find and replace that line. On mac the file ~/.vscode/extensions/salesforce.salesforcedx-vscode-core-<VERSION>/out/src/settings/pushOrDeployOnSave.js

[ChuckJonas]

@ntotten any movement on this one?

[arunmitteam]

I reduced it to 900 and still no luck. VSCode doesn't initiate the push or deploy for like 5-10 mins.

[lcampos]

This is addressed in version 46.4.0 of the extensions.

[ntotten]

@ChuckJonas This is fixed, please let me know your feedback in the newest release. :)

[ntotten]

Let us know your feedback. I am hoping this will be a big improvement.

[ChuckJonas]

@ntotten just tested it out with a couple scenarios:

First off, thank you for getting rid of the delay. If I make 500 saves in a day, that's ~ 40 minutes of my life back. Not to mention my attention span is only about 10s so that make it more likely that the deploy will complete before I get distracted by github or hacker news.

Also the subsequent save queue works great. I like that it prevents multiple deploy requests from running at the same time. It does well combining metadata with "Save All" or when you make multiple saves after one is already running.

Feedback:

1: The 500ms delay is still _just_ barely noticeable. I assume this is here to catch the "Save All" scenario? Not sure how much you tested, but I imagine it could safely be half that and still function (I find that debounces of ~200-300ms are only noticeable if you are looking for them).

2: When multiple MD is included in a single req, failure of any seems to cause the rest to fail as well. Would be nice if this wasn't all or none.

3: Still would love to see some type of "dirty" tracking of previously failed deployments and including those files in subsequent saves (maybe only if it's still open in an editor). This would be super helpful when refactoring. Although as I mentioned above, you wouldn't want it to prevent other MD from going up.

[arunmitteam]

@ntotten I updated the extensions and CLI, still the push or deploy is not kicking in. Could anyone help on this? Now I have to copy paste the class manually from local to dev console for every change.

[lcampos]

@arunmitteam it looks like a different issue so lets follow up on the thread for issue #1451

[arunmitteam]

Sure, thanks!