Yeah, it's basically this. I'm running this as an initContainer for my K8s-based deployments. Took me a bit to get everything going, but my stack is pretty much similar to OP's article, although not quite as advanced in the automated-deployment of containers and monitoring. I'm not at a position where usage needs heavy monitoring because I'm still in the pre-launch phase of things and I'm using this side project to learn stuff I've yet to get experience with at multiple companies.
You can use any normal DB migration tool. For k8s, I put the app's readiness probe to false, run the migrations and then toggle the probe back to true.
I wonder what happens during blue green or canary deployment?
if your migration changes database schema in a way that affect previous version negatively?
is it even possible to do blue/green deploy if your schema changes radically?
It's fine if you make the changes backwards compatible a version. And in general, any change can be done in a backwards compatible way (although it can be a PITA)
He's using Django, so most likely Django Migrations which is built into that framework. If you're using Flask, you're probably using Alembic with SQLAlchemy. Those are the two main ways to handle schema migrations in Python.