Saboteur

Да просто три енвайрнмента.
1. DEV
удобный доступ для всех, чтобы могли залить, зайти, посмотреть, поковырять. С точки зрения CI/CD возможно автоматический деплоймент на него сразу после сборки. Ну это зависит от проекта.

2. TEST
Максимально близкий сетап к продакшену, доступ закрыть, деплоить только через CD (чтобы тестировалось не только приложение но и сам процесс деплоймента). Возможность потестить перформанс, как на проде.

3. Прод.
ну тут нечего описывать.

Можно немнго варьировать, но это основные предназначения дев и тест. При наличии лишних ресурсов, можно добавлять препрод, DR, различные тестовые, авто, уат и так далее...

Обсудить это с заказчиком.
Если он понимает, как запустить проект, или наймет кого-то - просто можно архив на почту с краткой инструкцией как билдить.
Если не понимает, можно договориться что он купит хостинг, даст вам временный доступ, а вы там все поднимете за отдельную плату.

Что значит "принято". Это зависит от проекта и ваших предпочтений.
Нет явных общепринятых решений, так как одинаковых проектов немного.

Если у вас единственное приложение, то под него можно просто настроить сервер и без докера и с докером.
Если компонентов очень много, то чистый докер уже будет мало и сложно, нужно использовать оркестратор (кубернетес или опенщифт). Но можно и просто виртуалки/железки настроить.
Докер налагает свои моменты, но упрощает поддержку на будущее.

так а бутылочное горлышко где?
Если база тормозит - кластеризуем, оптимизируем.
Если база не тормозит, а тормозит бэкенд - ставим какой-нить балансер и несколько бэкендов к той же базе.

В общем выясните что больше всего страдает от нагрузки

"Хочется поменять процесс и на базе TeamCity добавить авто-тесты и некоторую автоматизацию чтобы было так (feature-ветки думал не использовать, так как у нас много небольших правок, а ветки добавляют оверхед):"

В том-то и дело, что авто-тесты без фича веток не очень хорошо будут работать.

Подробнее:
Автотесты обычно должны триггериться на коммит. Но это также означает, что разработчик не тестирует у себя локально приложение, а просто коммитит и ждет ответа от автотеста.
А если он будет коммитить в мастер - то один разработчик может сломать билд для всех.

Если использовать отдельную ветку для автотеста, опять же в нее может закоммитить несколько разработчиков и будет неясно кто кому что сломал.
Поэтому и используется фичабренчи - каждый разработчик создал себе фичабренч типа feature/lalala, и автотест реагирует на коммит в любой бренч по маске feature/*

Если тест успешен - тогда можно мержить в мастер - обычно для этого используется какой-то промежуточный инструмент перед гитом - gitlab, gerrit, bitbucket, где удобно настроить создание pull request-ов так, чтобы они не позволяли мержить, пока нет 1 ревью и 1 успешного билда.

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

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

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

напишите скрипт на bash, который скопирует файл на удаленный сервер и перезапустит на нем нужный процесс (tomcat или вашу java)

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

Можно настраивать CI, можно разводить agile процессы, но главное - выяснить требования заказчика, и подстраиваться под них.