Deploy On Save Performance Update

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.

[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.

[lcampos]

This is addressed in version 46.4.0 of the extensions.