How to properly delp on AWS?

Question

Amazon Web Services

Help me understand gentlemen, I'm completely confused what's what
There is a project on the standard stack:
Express / React / Webpack

Everything is going, everything is great, everything works.
But every time during the deployment to prod, users start whining that the site is down, not working, and so on.
I noticed that after clearing the cache, everything works.

The next solution was to add a hash to the file name file.hash2.js
AND save the old file to /dist file.hash1.js

That is, if the user had the application open, everything worked, after the reboot new files were pulled up
Teamlead says that it is bad practice to keep old files in dist and I should find another solution, which he did not say, I have no experience in this, before all I did was layout.

How to properly organize production build so that users do not even understand that everything has been updated for them

Answer 1

The file name with its hash or version is the norm! In addition to the jambs of browsers that cache what is impossible in various boundary situations, there are also clumsy providers that make this caching transparent.
The simplest example of two versions running at the same time is the ability to keep running during an upgrade.
The database, backend, and frontend may touch different versions at the same time. While physically the base and backend can use several different machines at once during the update, you cannot atomically change versions everywhere at the same time
And not only updating files can break everything. The update process almost always interrupts business processes related to updated data in a simple way, this is especially noticeable if it is necessary to update the database, and this takes time (tens of minutes to hours), users at this moment can receive error messages or even a violation of the business process itself up to data corruption if this update did not take into account (for example, the state of objects, you enter a new intermediate state, and the old version does not take it into account, the old version of the backend can skip the new state, setting the wrong one from the point of view of the new version, or vice versa, set the new one where the old clients of it will not understand and will give errors).
By the way, the version with which the client works can be stored and taken into account in the session, so that the user does not accidentally jump in the middle of the business process by refreshing the page.
In hardcore cases, it may turn out that it is necessary to create an intermediate version, taking into account that the database can contain data from different versions at the same time, i.e. users who started working immediately before the update are sitting on the old version, new users are transferred to an intermediate version that can work with all three versions, we wait for the old users to finish working with the old version (this can take hours or even days, it all depends on the implementation and business processes), when there are no such ones left, the third finishing version is launched, with which the clients and backend of the intermediate version work correctly, we wait for the users of the intermediate version to disappear, we run the finishing scripts for eliminating the tails of the intermediate one (these can be temporary tables or extra data / tables from the old one).
It is very difficult to describe in a general way the jambs that can get out, and God forbid if you have the opportunity to stop work to update, but what if you have billions of records and you need to edit a structure that can take days or even weeks? Few people can afford to stop the business for such a period.

Answer 2

The easiest thing to not think about is to use aws beanstalk. There is a blue-green deployment there. When the system becomes more difficult, then you can crawl to AWS ECS.
Well, as for the team leader, you can only sympathize with him. The person is clearly not aware of the SDLC and what are the practices for withdrawing old versions from circulation. It is absolutely normal when 2 versions of a product work in parallel

Answer 3

Move your app to create-react-app.
It automatically collects all the files with hashes.
Next, distribute via CloudFront and, after building the application, load the build artifacts (s3 sync) into the bucket. After downloading, reset the CF distribution cache.
In order not to break the front, write the code completely backwards compatible within the last few deployments.
Think about the deployment strategy, etc. Up to forcing a reboot on the client on an event from the server.