У каждого сервиса свой репо, свои джобы, свои деплои, зачастую не связанные друг с другом.
Монорепа/мультирепа
Это вопрос для девелоперов, как вам удобнее. Монорепа используется обычно тогда, когда у ваших сервисов реально есть общий код. Если же нет, то проще в отдельных репозиториях.
Многие CI/CD можно настроить на пуш в определенные подкаталоги, и тогда разные сервисы в монорепе будут триггерить свои собственные джобы (teamcity например)
Версионирование
На усмотрение разработчиков. В мейвене есть плагины для автоматического semantic версионирования. Или можно руками. Самое простое - это мажорную версию проставляешь руками, а ci просто номер билда дописывает и/или хеш коммита в версию.
Откат
В случае с кубером/опенщифтом для этой задачи существуют healthcheck пробы, которые настраиваешь и все. Если приложение не прошло хелсчек при поднятии, то деполй фейлится и все - предыдущая версия автоматом будет продолжать работать. В случае баз данных и других вещей - разработчики должны писать скрипты для наката/отката, или если база маленькая можно делать бэкапы или снепшоты. Тут зависит от архитектуры
Как обновить 2+ сервиса одновременно.
Все верно. Либо у вас порядок деплоя сервисов предуказан в процессах, либо наполовину руками выводить. Но по хорошему такие несовместимости не должны приводить к крешу сервиса. Ну не будет временно работать фича Б в сервисе, потому что недоступен другой, и все. Поднимется этот другой сервис и все заработает. Это правильный и идеальный вариант, не мешающий деплойменту. Деплоймент проводится в небизнес время и никого не аффектит. Как минимум, подобные ситуации должны встречаться не так часто, поэтому вполне можно найти промежуток времени для таких нестандартных деплоев.
У него есть такие понятия как конфиг и секрет, но они монтируются в образ как файлы, что не всегда удобно.
И конфиги и секреты можно маунтить и как файлы и как переменные окружения. Дочитайте документацию.