svvvy

I thought it was correct to run the DB migrations for the new code first, then deploy the new code. While making sure that the DB schema is backwards compatible with both versions of the code that will be running during the deployment.

So maybe there's something I'm missing about running DB migrations after the new code has been deployed - could you explain?

Maybe I don't understand your point, but isn't this similarly false equivalency? The business models are for-profit and subject to change. But despite that, right now, there is a material difference in privacy.

Also I think it a bit humorous - "privacy tax" to me is when services like Google offer services at a cost to my privacy.

Location: Sydney, Australia

Remote: Yes (have experience), Preferred

Willing to relocate: No

Technologies: Engineering lead, Python, JavaScript, Go, React, AWS, CI/CD, DevOps, and more

Résumé/CV: Upon request

Email: scratchmassive (at-symbol) gmail (dot) com

15 years full-stack engineering experience wearing a myriad of hats.

I have found Celery to be a major pain. It's very complicated (Are your Celery tasks guaranteed at-most-once or at-least-once delivery? Are you sure?). There are bugs with the Redis broker that cause it to drop tasks: https://github.com/celery/kombu/issues/305

I heartily recommend: https://dramatiq.io/motivation.html - "if you’ve ever had to use Celery in anger, Dramatiq could be the tool for you".