Yii2 и deploy на сервер

Как правильно организовывать "выкладку" на сервер?
Разрабатываю на yii2 в development mode. Собрал я какой-нибудь master, залил на bitbucket - все, есть готовая ветка, которую можно выкладывать
на рабочий сервер. Что делать дальше? Как превратить ее в production? Или просто держать ветку в production и к ней уже присоединять свой development?
И что дальше? Какие то тулзы ставить, типа capistrano (кстати, куда он ставится?)? И он по запросу будет брать с ветки bitbucket.production.my-best-site и заливать
на рабочий сервер? А что делать с базами? На данный момент есть база с тридцатью таблицами. Как создать (и создавать дальше) миграции из них? Или залить дамп,
а дальнейшие действия уже делать миграциями?
  • Вопрос задан
  • 14833 просмотра
Решения вопроса 2
Первый деплой:
git clone
composer install
yii init
#правите локальные конфиги (прописываете базу)
yii migrate


следующие деплои:
git pull
composer install
yii migrate


миграции создаем ручками
yii migrate/create createUserTable
и правим файл миграции
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
правильно организовывать "выкладку" на сервер

У каждого свои подходы. В общем случае, выделяют следующее:

Есть ветка master, в которой находится production код, есть ветка staging, в которой находятся фичи, которые нужно тестить. Есть кучи feature-бренчей, которые можно мерджить только со staging, а после того как код в стэйджинге стабилизировался, можно мерджить ветку в продакшен.

Подробнее о таком подходе можно почитать у фаулера, feature-branch. Есть еще другие методологии, типа feature-switch, а еще можно вообще не париться. Все от проекта зависит, количества разработчиков и все такое.

По поводу же выкладки на сервер - самый пожалуй правильный способ, использовать ansible или подобные штуки, и запускать сборку на CI сервере после успешного прогода тестов (что куда лить можно вешать по пушу в соответсвующую ветку).

Миграции в контексте yii придется делать руками, причем сразу при реализации каких-то фич. Миграции все же создавались для версионизации структуры данных, так что это даже больше для разработчика, нежели для деплоя. Сразу хочу заметить, что лучше писать такие миграции, которые не ломают логику работы более старой версии приложений (то есть стараться не удалять поля у таблиц, а только разрешать ничего туда не писать, или таблицы не удалять). Хотя опять же зависит от проекта и команды. Автоматизировать создание миграций для схемы данных будет проблематично, ибо модели не дают надежной инфы о схеме (то есть из модели не сгенерить таблицу, хотя можно это реализовать).
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы