Для решения данной проблемы требуется обеспечивать обратную совместимость версий релизов. Другими словами все новые изменения не должны ломать старый код. Общий порядок деплоя новой версии происходит в 2 этапа:
1 - применение миграций и поднятие новой версии парралельно со старой,
2 - старая версия прекращает принимать новые запросы и останавливается при окончании обработки существующих соединенй (graceful shutdown).
По поводу приведенных примеров
1 - совершенно верно, проблем нет
2 - не обязательно, ведь в процессе деплоя может одновременно работать новый и старый код
3 - если речь идет о невозможности реализации обратной совместимости, то данную проблему следует избегать на уровне архитектуры и планирования. Красивого решения она не имеет, но есть варианты, либо потребуется полная остановка системы для применения несовместимых миграций. Либо потребуется реализация, которая позволит работать двум версиям кода и базы, с возможностью ручной синхронизации изменений произошедших со старой версией в момент деплоя.
