Asset versioning and deployments

[javiereguiluz]

Another question asked on Symfony Slack (@jderusse asked it):

regarding the new Encore component and asset versioning (http://symfony.com/doc/current/frontend/encore/versioning.html) what is the simplest strategy to avoid 404 during a deployment (1) user gets http page pointing to asset version A, 2) a new version B of the app is deployed, 3) user ask for asset A which no longer exists)
Why not using a "queryString" strategy like describe in http://symfony.com/doc/current/frontend/custom_version_strategy.html

[stof]

Well, the query string strategy is possible:

• disable the versioning at the Encore level
• configure your Symfony project to use either a static version (if you are fine with busting the whole asset cache at once) or https://packagist.org/packages/incenteev/hashed-asset-bundle to use a different version for each asset

[weaverryan]

Stof's idea is 100% valid (nice to remember that Encore adds new strategies, but doesn't replace old strategies).

The solution in Encore depends on how you deploy. If you use something like EasyDeployBundle or Ansistrano/Capistrano, there shouldn't be a problem because you fully deploy the new assets before changing the symlink - i.e. while you're deploying, old traffic still hits your old assets. If you're doing something simpler - e.g. a git pull and then running encore on your production machine, then removing .cleanupOutputBeforeBuild() should be enough. Basically, don't delete the old assets. And if you're rsync'ing from one machine to production (including rsyncing the newly built assets), you will have issues (as the old assets will be deleted before your Twig cache is cleared / the HTML points to the new paths). But if you're worried about your assets 404'ing for a short period of time, I think the proper solution is to make your deploy a bit more sophisticated.

@jderusse wdyt?

[stof]

@weaverryan there is another case which can break, even with a more complex deployment. If you use require.ensure() or import() to split some JS code into a separate bundle (to lazy-load it), the lazy-loading could end up with a 404 if the page was loaded before the deployment (and so has the manifest with the old URL for the lazy bundle) but the lazy-loading itself happens only after the deployment (when the user clicked on some button)

[stof]

Note however that a query-string based approach will not make this work fine all the time though: you will not get a 404, but you will get the new code for this lazy bundle, which might be incompatible with all other assets (which were using the old code)

[weaverryan]

The only fool-proof approach is a "never delete old assets" approach... or at least a "only delete old assets... after some time has passed). This is pretty standard if you're using a CDN - e.g. CloudFront I believe keeps your old assets for 24 hours.

In summary:
A) Best Solution: Don't delete old assets, either by removing cleanupOutputBeforeBuild() or using a CDN that stores your old asset URLs for a little while
B) Great Solution: Use a decent deploy (e.g. the Capistrano philosophy) where you completely finish deploying and building your code before new traffic hits things. You shouldn't see any 404's, except in edge-cases (that Stof mentioned).
C) Not Great Solution If you have a deploy that continually serves traffic and deletes the old assets (e.g. an Rsync solution), your assets will 404 for a little while during deploy. Either make your deploy process better or use a different versioning method (like what Stuf suggested)

There's nothing to do in Encore, but we could add a small note about this in the versioning section.

[jderusse]

there shouldn't be a problem because you fully deploy the new assets before changing the symlink - i.e. while you're deploying, old traffic still hits your old assets

I'm not agree, time between fetching the html code and the asset is > 0 (specially when the html page was cached (private or public cache)).
Your deployment trigger may occured during this time interval. This is true for symlink, container rolling update, blue green.

Here you got 2 options to avoid 404 on assets:

• be sure to maintain several versions as long as necessary (ie. store assets in shared folder - or in a CDN/Proxy)
• fallback to as default version (ie. using queryString) . But as @stof sayed, instead of having a 404 error, you may got an unexpected version of the asset...

NB: you can use option 2 with a reverse-proxy in charge of serving oudated assets.

[stof]

@jderusse if the reverse-proxy can serve outdated assets which are not on the disk anymore, it also works for the path-based versioning though.

[stof]

There is a case where you will absolutely want to implement versioning at the webpack level though: when using code-splitting with import() (or the older require.ensure()). Assets loaded by these methods will not go through the Symfony Asset component, and so we cannot rely on the Symfony versioning for them.
This can either be done through explicit versioning or by ensuring that the file names generated for these additional chunks include the chunk hash even when versioning is not enabled for normal bundles (not sure whether it is possible)

[weaverryan]

I'm going to close this (see the open docs issue) - we'll document this as well as possible