(Инструкция, которую приходится копировать из проекта в проект, поэтому пусть будет и в блоге.)

Предполагается, что Deployer доступен уже в проекте, либо как файл `./dep`, либо как установленный composer пакет через `./vendor/bin/dep`. Он добавляется и хранится в гит-репозитории.

Также важно настроить конфиги, указав хост в `./deploy.php`. Они также хранятся в репозитории.

Обычные / регулярные деплои

`./dep deploy `, где в качестве можно выбрать любой хост из deploy.php файла. В этом файле у хоста указана нужная ветка. Однако, делать это обычно не нужно, так как на проекте настрое Gitlab CI (см файл `.gitlab-ci.yaml`), который зарелизит код по коммиту.

Как сменить деплой-ветку для хоста

Предположим, вы хотите сменить на `dev` ветку с `develop` на `feature/TASK-82-history-mypractice`.

Простой и быстрый вариант для быстрых тестов

Вы можете это сделать, поменяв `→set(’branch’, ’feature/TASK-82-history-mypractice’)` в deploy.php для хоста `dev`, а потом запустить `./dep deploy dev`.

Этот способ хорош, если хочется быстро показать ветку, и мы не ожидаем, что будет много фиксов, так как Gitlab CI всё ещё останется настроен на `develop` ветку. И поэтому:

• при коммите в `develop` ветку, Gitlab CI запустит `./dep deploy dev` и задеплоит `feature/TASK-82-history-mypractice` на `dev`. Но это неправильно, так как мы не хотим деплоить эту ветку на дев по коммиту в `develop`, мы хотим деплоить по коммиту в ветку `feature/TASK-82-history-mypractice`
• при коммите в `feature/TASK-82-history-mypractice` ветку CI ничего не сделает, так как в версии конфига `.gitlab-ci.yaml` из этой ветки нет никакого правила для ветки `feature/TASK-82-history-mypractice`.

Правильный вариант с обновлением Gitlab CI правил

1. Переключиться в `develop` ветку, изменить branch в deploy.php для нужного хоста и в `.gitlab-ci.yaml` изменить параметр `only:` для этого же хоста.
2. Закоммитить. CI теперь не запустит деплой на `dev`, так как мы поменяли ветку на `feature/TASK-82-history-mypractice`.
3. Переключиться в ветку `feature/TASK-82-history-mypractice` в git и вмерджить в неё свежий `develop`. Вместе с develop придут изменения для `deploy.php` и `.gitlab-ci.yaml`. Поэтому если сразу закоммитить вмёрдженное, то Gitlab CI запустит деплой feature-ветки на `dev`.
4. Важно! Перед мерджем ветки в `develop` нужно изменить `deploy.php` и `.gitlab-ci.yaml` и заменить feature-ветку в них обратно на `develop`. Потом смерджить и Gitlab CI, увидев этот коммит в develop, сразу продеплоит `develop` на `dev`.

Как переключить хост с feature1-ветки на другую feature-2 ветку:

1. Переключиться в develop ветку и изменить в ней `deploy.php` и `.gitlab-ci.yaml`, указав feature2 вместо feature1 для нужного хоста.
2. Вмерджить develop ветку сначала в feature1 ветку, потом в feature2 ветку.

Удобные команды

1. `./dep ssh ` — команда подключится к хосту по конфигу из deploy.php и сделает перейдёт в папку current релиза.
2. `./dep run «»` — запускает команду на удалённых серверах. После запуска она спросит на каких серверах запустить.
3. `./dep ` — запускает любую определённую в deploy.php `task(’’, )` на нужно сервере.
4. Можно указать «теги» для серверов и запускать всё выше написанное сразу пачками.

Первый деплой / создание окружения

1. `./dep deploy develop2` — первый раз закончится с ошибкой, но Deployer создаст структуру файлов по пути из deploy.php для develop2. Он создаст папки
   1. `/var/www/dev.project.name/releases` — тут будут располагаться папки с каждым новым релизом и копиться последние N штук.
   2. `/var/www/dev.project.name/shared` — тут хранятся файлы, которые должны быть сохранены и перенесены между релизами. Например, логи, web/assets, storage, etc. Эти папки задаются в deploy.php как shared_folder и shared_files. Во время деплоя эти папки будут заменены на симлинки из shared папки.
   3. `/var/www/dev.project.name/current` — симлинк на последний успешный релиз из папки releases.
2. После создания структуры нужно перенести/создать файлы в shared:
   1. `./shared/.env`
   2. `./shared/web/XXXXXXX` — можно посмотреть, какие папки создадутся на сервере, либо какие папки указаны в shared_folder в deploy.php (с учётом тех, что указаны во фреймворк-специфичном recipe, подключённом в deploy.php).
3. Повторить деплой `./dep deploy develop2`
4. Также нужно залить данные в БД / импортнуть из sql дампа по параметрам из `.env`.