@Artem0071
Безработный mr. Junior

Как правильно деплоить проект?

Ларавел используется как апи для фронта и приложения

Есть ли какая то инструкция / шаги по которым стоит делать перенос с локалки на хостинг/сервер?
(на серве)

Как мне сейчас представляется:
1) Делаю git commit -> push // чтобы была какая то версионность и можно было вернуться
Так же читал про то что можно как то сделать так чтобы с гита сразу заливался на сервер, но так и не понял как. Есть какая то нормальная инструкция?
2) В ларавел есть такая вещь как миграции. Я разобрался как с ними работать, но не понимаю как они будут работать когда будут какие то обновления произовдится
Если я на локалке создам еще какие то миграции, то как их переносить на сервер?
К тому же если использовать гит? Ведь гит же не сможет "произвести" миграцию?
3) Как сохранять пароли?
Сейчас все хранится в .env . И сейчас у меня бд находится на хостинге, а не локально. Как сделать так, чтобы на локалке я подсоединялся к одной бд, а на хостинге ларавел уже подсоединялся к другой?
  • Вопрос задан
  • 1417 просмотров
Пригласить эксперта
Ответы на вопрос 6
  • Maksclub
    @Maksclub
    maksfedorov.ru
    по п.1 — делается черех веб-хук GIT
    по п.2 — миграции также как и любые др файлы проекта передаются через GIT на продакшн-сервер
    а вот чтобы их применить — нужно на продакшене их накатить
    по. п3 — пароли индивидуально на сервере задаются, их нельзя пихать в GIT


    Чтобы все автоматизировать по цепочке:
    pushвеб-хукpull+migrate+composer update+npm install

    Можно использовать полноценные инструменты для деплоя:
    Deployer
    Capistrano
    Ответ написан
  • lomnev
    @lomnev
    PHP, Ruby developer. Корпоративные веб-приложения.
    1. Если без опыта начнете деплоить с хуками и миграциями как вам написали, рано или поздно положите production так, что замучаетесь откатывать базу данных.
    2. Чтобы наладить такой процесс необходим staging сервер с реальной базой данных и максимально похожий на production.
    3. Сначала нужно деплоить на него и прогонять функциональные тесты. И только в случае если они проходят, проводить production-деплой.

    Это конечно не относится к "деплою" трехстраничных сайтов-визиток с траффиком в 100 человек в день. Для них и Ctrl+S подойдет.
    Ответ написан
  • toxicmt
    @toxicmt
    CTO at hexlet.io
    Если не брать в рассчет современные подходы на основе докера, то самый универсальный способ - использовать ansible и его модуль docs.ansible.com/ansible/latest/deploy_helper_modu...

    Если погуглить 'laravel deploy ansible', то вы найдете множество статей и репозиториев на гитхабе, из которых можно почерпнуть всю необходимую информацию.

    p.s. И никогда не используйте баш скрипты для подобных задач.
    Ответ написан
  • @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
    Ответ написан
  • @ProSerg
    Предлагаю воспользоваться готовыми решениями типа gitlab ci. Копать в сторону агентов Gitlab Runner и написание ci сценариев. . Там есть возможность deploy, а также разворачивать кластер kubernetis. Gitlab бесплатный сервер с широким набор инструментов, есть возможность его развернуть на собственном сервере на линуксе. Ставиться одной командой.
    Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы