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

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

SELECT city, COUNT(city) AS count, string_agg(vendor, ',') FROM ctable GROUP BY city

https://docs.microsoft.com/en-us/sql/t-sql/functio...
https://www.postgresql.org/docs/9.5/functions-aggr...

Возможно нужно использовать GROUP_CONCAT, зависит от БД

SELECT city, COUNT(city) AS count, GROUP_CONCAT(vendor) FROM ctable GROUP BY city

www.sqlines.com/mysql/functions/group_concat