Ответы пользователя по тегу Развёртывание ПО
  • Как правильно деплоить проект?

    @jumale
    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
    Ответ написан
    Комментировать