Станислав Бодро́в

Gitlab и его CI это отдельная сага по поиску ошибок и устранению проблем. Механзмов отладки и поиска неприятностей даже не припомню. Один из вариантов скачивать вывод в виде текстового файла и парсить регулярками. Если файл всё в себя вместит.
Функционал программы развивают до безобразия. Только когда доходит до поиска неисправности или попыток отладить, чтобы понять почему не работает, всё крайне печально. Особенно с CI
Поэтому алгоритм разрабатываешь сам, набивая шишки.

Есть веб-проект, над которым работают несколько людей.

В подавляющем числе случаев распространённая ситуация.

Периодически в процессе разработки надо смотреть "что получилось", производить ручное тестирование и так далее. Я сломал голову, пытаясь понять, как это красиво по-современному организовать.

Определись с подходящим для проекта и команды git flow.

При коммите (точнее, при пуше) всё собирается докером и запускается контейнер на сервере. Но разработчиков несколько! Как запускать? На разных портах? Тебе 8081, тебе 8082? А ещё есть СУБД, к которой тоже нужен доступ - залезть гразными руками и посмотреть-поправить. Тебе 5432, тебе 5433 и так далее?

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

Потом, бывают ситуации, когда разработчик откладывает задачу-ветку и начинает работать над другой задачей в другой ветке. Что тогда?

Если желания наведения порядка на проекте нет, создавай отдельный деплой под каждую ветку.

правильно реализовать continuous deployment для запуска миграций

через предварительное резервное копирование. Всяко бывало

Настроить правильно gitlab Runner