Advanced deploy sequence : is that even necessary?

This is a kind of “good practice” question. I have a multi-services architecture, with a server, a worker and a beat sharing the same DB. My fear is: what happens if the worker is running tasks that are writing to the DB while it has just been migrated by the pre-deploy command of the server?

The sequence is this:

  • all services running
  • all “auto-deploy” have been disabled, it’s all manual.
  • new deploy of server is triggerred, and follows sequence as described in Deploying on Render – Render Docs
  • as part of the pre-deploy command, the DB is migrated to the new schema.
  • the worker is still running on old code, and write data with the old (wrong) schema…
  • ???

Could deploying all these services at once with auto-deploy be a solution? Looks like quite uncertain to me.

As of now, I have a deploy script (executed by GH actions) using the Render REST APIs. It suspends the worker and beat services first (whatever they were doing at that time…), then send a deploy command to the server, wait for it to be successfull, then resume the worker and beat (which will trigger a deploy of the latest commit – which is actually bad I realise, since it may be faulty).

Anyway, does someone do the same? Am I alone worrying for no real reasons? Thanks a lot.