Когда-то давно тоже был опыт создания сайтов по ТЗ и это была боль - приходилось делать долгосрочные эстимейты (которые никто никогда не угадывал), тратить кучу времени на ТЗ, чтобы не пропустить ни одной детали, затыкать заказчику рот этим ТЗ когда он через месяц менял свое мнение.... ну и т.д.
С тех пор только спринты - в начале приблизительно оцениваем сложность проекта чтобы определиться с инструментами разработки и обязуемся через N недель выдать MVP. А дальше "любой каприз за Ваши деньги" - новые фичи == новые спринты == платите. Клиенту останавливаться после первого же спринта смысла нет - он заинтересован в готовом продукте, а смена исполнителя это доп. траты. В то же время и у клиента и у исполнителя есть шанс не продолжать сотрудничество после определенного спринта если вдруг испортятся отношения. Клиент сам рассчитывает за что он платит и когда остановиться.
Я правда уточню, что в последнее время я работаю в большой компании и в моем случае "клиенты" - это стейкхолдеры, которые работают в этой же компании. Но в данном случае они мало отличаются от "аутсорсного" клиента, потому что они являются заказчиками проекта, у них есть определенный бюджет и наше сотрудничество выглядит именно так как я описал выше.

1) Инициатор деплоя: это может быть как гит-хук, так и допустим вызванная вручную команда. Для начала рекомендую не зацикливаться на хуках, а вызывать в ручную. Если деплоите не так часто, то этого будет вполне достаточно и более безопасно.
2) миграции - это всего лишь sql команды которые меняют бд. Запуск миграций - это то же самое если вручную запустить любой sql клиент у себя на компьютере, присоединиться к бд и начать добавлять/удалять таблицы и столбцы. Я веду к тому, что миграцию на prod сервере можно выполнить и с локальной машины, если миграции будут выполнены с продакшн конфигурацией.
3) Конфигурация. В случае с .env файлом это можно сделать таким образом:
- создаем файл .env.dist в котором указываем все переменные которые требуются для приложения, но оставляем значения пустыми
- комитим .env.dist в репозиторий. Теперь у нас в репозитории есть шаблон по которому мы можем создать .env файл на локальной машине и заполнить значения переменных
- добавляем .env в .gitignore (если .env уже был закомичен, то надо его сперва удалить и закомитить удаление, иначе .gitignore будет неправильно игнорировать .env)
- теперь когда .env игнорируется гитом, можно скопировать наш шаблон .env.dist как .env и заполнить значения переменных. Каждый, кто устанавливает этот проект с нуля у себя на машине должен будет сделать то же самое.

Вообще деплой можно разбить на несколько этапов:
- инициатор деплоя (любое событие по которому начинается деплой)
- сборка проекта (подготовка всех файлов в то состояние в котором они должны отправиться на prod сервер и заменить собой текущие файлы на сервере)
- тестирование проекта (запуск юнит и функциональных тестов, чтобы убедиться что мы заливаем рабочий код)
- собственно перенос проекта на сервер
- выполнение post-deployment команд, которые должны быть выполнены когда новые файлы уже на сервере (например миграции и т.п.)
- интеграционные smoke-тесты (можно оправить GET запросы на ключевые страницы нашего prod сервера и проверить, что в ответах содержится ожидаемый текст или HTML, это делается чисто для того чтобы убедиться, что после деплоя сервер все еще живой и отображает нужные страницы)

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

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

У меня нет опыта с ларавел, но для симфони проекта я бы написал приблизительно такой bash скрипт:

# если Вы деплоите с локальной машины,
# то как минимум не стоит собирать проект из файлов с которыми Вы работаете в редакторе,
# потому что там у нас могут быть незакомиченые изменения, локальные настройки
# и еще много чего, что не должно попасть на prod сервер
# поэтому проект будем собирать с нуля в отдельной директории, например "build"
# (которую тоже нужно предварительно добавить в .gitignore)

# очищаем директорию build и заходим в нее
rm -rf build
mkdir build
cd build
# клонируем наш проект
git clone git@example.com/user/project . # "." клонирует в текущую директорию
git checkout master
# создаем конфиг для prod
cp .env.dist .env
# дальше надо заполнить значения переменных в .env файле
# для начала можно просто поставить скрипт на паузу в этом моменте и заполнить вручную,
# а в будущем как нибудь автоматизировать этот процесс,
# например хранить файл с prod конфигами где нибудь на машине
# и во время сборки копировать их в проект

# устанавливаем вендоры
composer install
# прогоняем юнит и функциональные тесты, чтобы убедиться что мы не зальем какой нибудь баг
vendor/bin/phpunit -c unit.xml
vendor/bin/phpunit -c functional.xml
# прогреваем кеш
bin/console cache:clear --no-warmup --env=prod
bin/console cache:warmup --env=prod

# выполняем любые другие шаги по подготовке проекта
# ...

# теперь наш проект готов к заливке на сервер
# например через scp
scp -r . <username>@<hostname>:<destination path>

# наконец, можно накатить миграции баз данных
php app/console doctrine:migrations:migrate --env=prod

# запускаем смок-тесты которые покажут, что деплоймент прошел успешно
vendor/bin/phpunit -c smoke.xml