Yii2 и deploy на сервер?

Question

[slip31]

Как правильно организовывать "выкладку" на сервер?
Разрабатываю на yii2 в development mode. Собрал я какой-нибудь master, залил на bitbucket - все, есть готовая ветка, которую можно выкладывать
на рабочий сервер. Что делать дальше? Как превратить ее в production? Или просто держать ветку в production и к ней уже присоединять свой development?
И что дальше? Какие то тулзы ставить, типа capistrano (кстати, куда он ставится?)? И он по запросу будет брать с ветки bitbucket.production.my-best-site и заливать
на рабочий сервер? А что делать с базами? На данный момент есть база с тридцатью таблицами. Как создать (и создавать дальше) миграции из них? Или залить дамп,
а дальнейшие действия уже делать миграциями?

Answer 1

[Александр Зеленин]

Первый деплой:

git clone
composer install
yii init
#правите локальные конфиги (прописываете базу)
yii migrate

следующие деплои:

git pull
composer install
yii migrate

миграции создаем ручками
yii migrate/create createUserTable
и правим файл миграции

Comments

[Сергей Протько]

Это как-то грустно...

[Александр Зеленин]

@Fesor вполне может быть. в этом деле только ищу свой подход. Но это официальный подход под yii2, без использования сторонних решений типа phing и capistrano

[Сергей Протько]

@zelenin, ансибл и докер. Правда с этим подходом сходу разобраться тяжко, но очень многообещающая штука этот докер.

[Олег Илюшин]

В Yii2 Advanced Application есть отличный механизм environments.
Т.е. вместо шага "правите локальные конфиги" при правильной конфигурации достаточно выполнить:
```
./init prod
```

[slip31]

Это да. Файлы он перепишет. Но что делать с самим фреймворком. Допустим, на гитхабе хранится только само приложение без папки vendor. что первым ставить на сервер? Если ставить yii2-app, то потом все перезапишется

[Александр Зеленин]

@zmeykas вы неправильно понимаете смысл enviroments. На этом шаге должны разворачиваться конфиги, зависящие от окружения, например в dev-окружении в конфигах будет debug, gii итд. А локальные конфиги должны быть пустые и не содержать паролей от баз, поэтому правятся локально.

[Олег Илюшин]

@zelenin видимо это вы неправильно понимаете смысл enviroments. Советую перечитать www.yiiframework.com/doc-2.0/guide-apps-advanced.html

Да существуют конфиги с приставкой -local, они используются разработчиками в ходе разработки, исключены из репозитория чтобы не мешать друг-другу. На деплой они никоим образом не влияют.
Также такие конфиги могут использоваться на production сервере для хранения информации, которую в репозитории хранить небезопасно.

[Александр Зеленин]

@zmeykas вы говорите то, о чем я раньше сказал. Небезопасная информация - это как раз любые реквизиты. Эти реквизиты и должны храниться в локальных конфигах, исключенных из репозитория. Именно поэтому их и нужно править после деплоя.

[Олег Илюшин]

@zelenin я вас понял, не буду спорить. У несколько проектов не использующих локальные конфиги на production, все реквизиты прописаны в environment конфгах. Я доверяю своему репозиторию, но осознаю что такой подход гораздо менее безопасен. Давайте посчитаем это более простым, но менее безопасным решением поставленной задачи деплоя.

Кстати, для более серьезных проектов использую Phing (www.phing.info)

[Александр Зеленин]

@zmeykas хранить так конфиги можно только для своих проектов. Для общественной разработки (приложение, которым будут пользоваться люди - cms или типа того) такой вариант не подойдет. Поэтому предпочитаю универсальные решения, тем более в локальном конфиге как правило только подключение к БД.

Phing пробовал, понравилось, но не смог подключиться к ssh на php 5.5.

Answer 2

[Сергей Протько]

правильно организовывать "выкладку" на сервер

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

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

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

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

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

Answer 3

[nikosid]

Мне понравилось использовать https://github.com/yii2tech/selfupdate