A neat trick with uWSGI is to dynamically set the number of worker processes to 0, which causes incoming requests to hang whilst waiting to be processed by no-longer-extant workers.<p>As long as you can apply DB migrations before the waiting requests timeout (and then set the number of workers back to something sensible) you can perform quite major upgrades without even dropping connections.
One thing worth noting about these rolling restarts that I didn't see in your post: if the new code isn't completely backwards-compatible, you can end up with bad states from having a mix of workers running. This negates a lot of the value of the rolling restart because it creates other failure modes.<p>For example, if you introduce a new ajax endpoint in the release, and a client hits a new worker generating a HTML page that calls it, but 90% of your gunicorn workers are still serving the old version of the app, 90% chance that you're going to 404 that request.
Rather than killing Gunicorn's child processes, I prefer to send SIGHUP to the master process.[1]<p>It's as simple as<p>`pkill -f --signal HUP "gunicorn: master \[procname\]"`<p>[1] <a href="https://gunicorn-docs.readthedocs.org/en/latest/faq.html?highlight=HUP#how-do-i-reload-my-application-in-gunicorn" rel="nofollow">https://gunicorn-docs.readthedocs.org/en/latest/faq.html?hig...</a>