Saboteur

И второй попутный вопрос: правильно ли что dev и prod работают на одном и том же контейнере?

Вы имеете ввиду из того же докер образа? Так и надо делать. Чтобы тестировать и запускать в продакшене одно и тоже.
Енвайрнмент-зависимые вещи настраиваются извне и прокидываются (сертификаты, креденшелы для баз данных, и т.п.)

А так - если вас решение устраивает, если вам оно понятно и в случае чего вы его можете легко модифицировать как вам нужно - да, вполне нормально.

У каждого сервиса свой репо, свои джобы, свои деплои, зачастую не связанные друг с другом.

Монорепа/мультирепа

Это вопрос для девелоперов, как вам удобнее. Монорепа используется обычно тогда, когда у ваших сервисов реально есть общий код. Если же нет, то проще в отдельных репозиториях.
Многие CI/CD можно настроить на пуш в определенные подкаталоги, и тогда разные сервисы в монорепе будут триггерить свои собственные джобы (teamcity например)

Версионирование

На усмотрение разработчиков. В мейвене есть плагины для автоматического semantic версионирования. Или можно руками. Самое простое - это мажорную версию проставляешь руками, а ci просто номер билда дописывает и/или хеш коммита в версию.

Откат

В случае с кубером/опенщифтом для этой задачи существуют healthcheck пробы, которые настраиваешь и все. Если приложение не прошло хелсчек при поднятии, то деполй фейлится и все - предыдущая версия автоматом будет продолжать работать. В случае баз данных и других вещей - разработчики должны писать скрипты для наката/отката, или если база маленькая можно делать бэкапы или снепшоты. Тут зависит от архитектуры

Как обновить 2+ сервиса одновременно.

Все верно. Либо у вас порядок деплоя сервисов предуказан в процессах, либо наполовину руками выводить. Но по хорошему такие несовместимости не должны приводить к крешу сервиса. Ну не будет временно работать фича Б в сервисе, потому что недоступен другой, и все. Поднимется этот другой сервис и все заработает. Это правильный и идеальный вариант, не мешающий деплойменту. Деплоймент проводится в небизнес время и никого не аффектит. Как минимум, подобные ситуации должны встречаться не так часто, поэтому вполне можно найти промежуток времени для таких нестандартных деплоев.

У него есть такие понятия как конфиг и секрет, но они монтируются в образ как файлы, что не всегда удобно.

И конфиги и секреты можно маунтить и как файлы и как переменные окружения. Дочитайте документацию.

Процедуру деплоя на прод нужно изменить
Вместо git pull на продакшене, собирайте прод дистрибьюшн на промежуточном сервере в какой-нить tgz и выкладывайте его на прод уже скомпилированным.

git pull не должен ломать права доступа на уже существующие директории, только если вы добавили новую директорию.

А git clone естественно создает все заново.

git хранит только executable bit для исполняемых файлов, все остальное создается с дефолтными правами согласно umask.

Эм.
В первую очередь нужно смотреть логи.
Если там недостаточно информации, ковыряешь скрипты деплоя и добавляешь там много echo на всех важных моментах, чтобы логи были полезными и понятными.
Потом снова смотришь логи.
Опять же в данном вопросе информации вообще нет. Jenkins может быть настроен очень гибко, по общим фразам никто не знает. Может у тебя независимые джобы для деплоя на разные енвайрнменты, может у тебя pipeline на груви, может еще что.

То есть по канону, даже если в одном файле надо букву поменять - следует запускать полный цикл выгрузки?

По канону вам не нужно ничего запускать. Все запустится автоматом и вы просто не паритесь.
Вдобавок нужно понимать, что в идеальном случае, у вас должны быть пройдены автоматические тесты, разные уведомления и другая бюрократия, которая тоже автоматизирована.

В этом случае вы просто не мучаетесь выбором, а просто кодите.
Ну а одна буква это может быть и - на +. Без тестирования в продакшен?

Есть домен и статический IP. Есть роутер Ericsson, есть ноут с Apache, PostgreSQL и JDK. Джарники залиты в Tomcat webapps.
Дальше полагаю необходимо настроить роутер и какова необходимость в установке и настройки IPTABLES?

Так вам нужно апач или томкат? Это же разные сервера, они друг другу не обязательны.

IPTABLES не нужно, и домен необязательно, если вы внутри локалки ходите на локальный айпишник своего сервера.

Будет сервер на питоне, со своими возможностями.

Нужно понимать, что сервер на питоне не обладает тем же функционалом, что nginx или apache (например rewrite, basic authorization, несколько сайтов, поддержка https/ftp и другое), но если этот функционал вам не нужен - запускайте хоть на бейсике.

1. Копировать можно просто по scp
2. Выкладывать можно не только под basic auth, а еще и в запароленных архивах

Затем его или деплоить, или создать деплоймент пакадж и выложить его в бинарный репозиторий, или хотя бы на sftp

Создается шаблон для коммит-мессаджей, в котором разработчики в нужном месте пишут текст, в том числе и для релиз нотов.
Официальные билды запускаются на дженкинсе, после успешного билда вызывается скрипт на питоне, который обходит новые коммиты и создает релиз ноты.
Питон удобен, потому что есть готовые либы для поста в ту же Жиру...но можно и встроенным в Дженкинс способами что-то делать.