Как правильно деплоить проект?
Как мне сейчас представляется: 1) Делаю git commit -> push // чтобы была какая то версионность и можно было вернуться Так же читал про то что можно как то сделать так чтобы с гита сразу заливался на сервер, но так и не понял как. Есть какая то нормальная инструкция? 2) В ларавел есть такая вещь как миграции. Я разобрался как с ними работать, но не понимаю как они будут работать когда будут какие то обновления произовдится Если я на локалке создам еще какие то миграции, то как их переносить на сервер? К тому же если использовать гит? Ведь гит же не сможет "произвести" миграцию? 3) Как сохранять пароли? Сейчас все хранится в .env . И сейчас у меня бд находится на хостинге, а не локально. Как сделать так, чтобы на локалке я подсоединялся к одной бд, а на хостинге ларавел уже подсоединялся к другой?
- Вопрос задан более трёх лет назад
- 7150 просмотров
- Вконтакте
Если не брать в рассчет современные подходы на основе докера, то самый универсальный способ - использовать ansible и его модуль docs.ansible.com/ansible/latest/deploy_helper_modu.
Если погуглить 'laravel deploy ansible', то вы найдете множество статей и репозиториев на гитхабе, из которых можно почерпнуть всю необходимую информацию.
p.s. И никогда не используйте баш скрипты для подобных задач.
- Вконтакте
1. Потому что это легко превратиться в реальное программирование (можно посмотреть во что заводят шеф и папет) 2. Придется руками обеспечивать идемпотентность. А это страшная вещь, ради, во многом и появились эти системы 3. Баш не может в доставку. Вот написали мы эти скрипты, а дальше как они попадут на кластер? как выполнить только часть задач? как выполнить только то что свалилось? и тысяча других вопросов
по п.1 — делается черех веб-хук GIT по п.2 — миграции также как и любые др файлы проекта передаются через GIT на продакшн-сервер а вот чтобы их применить — нужно на продакшене их накатить по. п3 — пароли индивидуально на сервере задаются, их нельзя пихать в GIT
Чтобы все автоматизировать по цепочке:push → веб-хук → pull+migrate+composer update+npm install
Можно использовать полноценные инструменты для деплоя:DeployerCapistrano
- Вконтакте
- Вконтакте
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 скрипт: