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