We just deployed our new website on the same domain but with a different stack. the old stack was create-react-app and it had service workers which is caching for offline usage.
Now after the new version is deployed, it still shows up the old version because of the cache. is there anyway i can force all users who visits the website to clear cache automatically?
Related
In react I am using the service worker for push notification service, so during a production release without noticing service worker config, it was pushed to live and the site data got cached indefinitely in many of user's browsers.
However now this issue is fixed, but the users who were accessed that specific rollout are still seeing the old version of the site.
Is there any solution for this?
I've recently done a UI update for my website, the backend is all identical. I want to access the latest deploy (with the no-promote flag) from 'beta.my-website.com' but still access the 'normal' site from 'my-website.com'. Ideally this would dynamically serve the latest version, but if not could I set it statically to the URL with project ID? I have bought my domain from 123reg. Is there a way to direct to the latest version regardless of it's traffic serving status?
TL;DR Can you set up a 'beta' site at beta.mywebsite.com while still being able to access the live version on www.mywebsite.com on google cloud?
Any help would be greatly appreciated.
Thanks!
I don't think that can be done like that.
You could deploy to a different appengine project by putting a different project id and then have beta.mywebsite.com route to that project instead. The nice thing about this option is everything else would be isolated (i.e. no chance of your beta changes causing bad data in your production database, or tasks in your queues)
Another option would be to deploy to a different service within your project and use your dispatch.yaml to route beta.mywebsite.com to it https://cloud.google.com/appengine/docs/standard/python3/reference/dispatch-yaml
A third option would be to put beta as your version-id, and have your DNS redirect beta.mywebsite.com to beta-dot-your_project_id.appspot.com. However, when the user goes to beta.mywebsite.com they would ultimately see beta-dot-your_project_id.appspot.com in the URL bar. Also, when you're ready to go live, you would want to redeploy and promote that new version id and not promote the beta version-id.
We've build few services on Google App Engine, we've ship them into production and everything worked as expected. But now I have little issue with one of my integration service which runs on flexible environment. I've deployed serveral times new version and maybe some of deploys wasn't successfully finshed or something like that. Now I see in Stack Driver logging some error logs from running instances of some old version (by version id in "resource" property). It made me few problems with with some version "missmatch" in integration tasks. I don't see this old versions in GC CLI SDK or in web dashboard. I've tried to delete whole service and redeploy it, but after first deploy, there are still new log entries in Stack Driver. I've changed DB credentials to prevent older versions to make mess in DB ¯_(ツ)_/¯. Production environment now runs OK, but there are still some old services spamming logging with errors about DB auth. I cant find this old versioned instances anywhere except this new log entries. Is it normal behaviour? Do you have some tips?
I have a React/redux app which is deployed on CloudFront + s3. There is no static hosting enabled on the bucket. I understand that invalidating cache on a new deployment clears cache in all the edge locations and the new changes will be served up. But what happens to the active prod users when the cache is invalidated? Are they able to continue on the app without any errors? Does it get worse for the active users if the redux store structure changed in the new version?
Clearing the cloudfront cache will bring up the fresh content from your origin. However, that would not affect the existing production users. They would continue to be served from the cached content as long as their session continues.
That being said, they would be served the fresh content when their session restarts.
There would be no errors whatsoever.
Hope this helps.
I've been wondering the same thing for my React website, which is made up of many chunks. I wouldn't worry about your Redux state unless you're saving it to cookie/localstorage and loading it again. In that case you could write some migration check during loading. Or even have it versioned in some way.
Regarding caching, I don't recommend deleting any files for up to a year. That way your active users would still be able to download chunks while they're active on your website.
During deployment I upload all the new files and clear the cache on all *.html files to get the latest reference to js and css files.
By deploy, I assume they mean code changes are pushed to production?
If I had 2 or three devs working with me on a project, what is to stop them from pushing changes that break the production site?
What checks and balances do we have to avoid such error? Do you setup a staging and production environment in GAE, having someone manually verify everything appears to work before making live.
If you want to limit individual devs doing uncontrolled pushes to the code.google.com (from which the deploys happen), then arrange for one and only one local repository be the local repo-of-record, and only configure that one to know about the source.google.com 'origin' server. Integrations are pulled into that repo, and (when you're ready) push to deploy from there.
Here's how it works under the covers. When you use gcloud to set up a project, it modifies default/.git/config to know about source.google.com, and to use an authentication helper that ties in to oauth (re-using the token that gcloud auth login will store locally) to authenticate. To limit deployment, make this the integration repo, and configure dev repos to push to it.
If you set up a separate staging version of the app, it's a policy decision on your side about whether to use the same scheme, or let developers deploy to staging individually. The mechanism you'd use to configure this is all .git/config wiring.