то есть симфони рассчитана на то, что в команде есть админ или девопс который занимается настройкой окружения?

на это рассчитан любой проект, нет?

часто стартап состоит из одного человека

у нас в команде нет выделенного админа

и девопса

и там нет бабла на отдельного девопса который бы руками все делал) разве нет?

у нас в команде нет выделенного админа

сервера дырявые небось)

может и дырявые, но так начинают все и это нормально :)

я не говорю, что он должен быть, я говорю, что настройкой софта, установкой пакетов и так далее занимается отдельный человек, не само же приложение компилирует пхп экстешнны например

ну...

ну, экстеншены это другое дело.

фаерволом пользоваться умею

SYMFONY__ переменные

Уже можно без SYMFONY__.

ansible роли пишу

@Enleur хотите поискать уязвимости?:)

ну, экстеншены это другое дело.

как раз это и есть твое окружение непосредственное. А симлинки, права и прочая мелкая хуета - это должно настраиваться при стратегии депло

http://symfony.com/doc/current/deployment.html

как раз это и есть твое окружение непосредственное. А симлинки, права и прочая мелкая хуета - это должно настраиваться при стратегии депло

Но стратегию деплоя нужно где-то прописать, напрмиер в CI. Это крутое решение но ты не сможешь им пользоваться при разработке, локально. Есть проблема, есть и решение. Напришем свой bash скриптик со стратегией. который запсукает CI и так же сможем запускать мы при разработке чтобы переключаться между окружениями. Это же так происходит?

Но стратегию деплоя нужно где-то прописать, напрмиер в CI. Это крутое решение но ты не сможешь им пользоваться при разработке, локально. Есть проблема, есть и решение. Напришем свой bash скриптик со стратегией. который запсукает CI и так же сможем запускать мы при разработке чтобы переключаться между окружениями. Это же так происходит?

гм, а что нужно использовать локально? я что-то совсем не понял :)

Я по опыту знаю, что состояние приложения в момент разработки и на продакшене - это часто два очень разных состояния. Разница как и в конфигах так и в количестве входных скриптов и переменных окружения. Вот взять симфони приложение стандартное. В папке web есть app.php и app_dev.php.

у симфы чтобы ее использовать локально, должно быть два пунка - установленные вендоры и писабельный кеш

короче, я не совсем понимаю твой головняк. Есть тулзы, которые решают проблему деплоймента симфы

ок, может я загоняюсь :) у начинающих бывает.

тем более которые пришли с не очень "правильного" фрейма :)

то что на проде и то что локально различается только параметрами и входным файлом, и все

так что ты чет слишком много в это вкладываешь

+, как раз писал

или у тебя слишком много какойто фигни

в юии с конфигами вообще беда и их переключением, он енва к енву

ну в basic все как в симфе. там все просто

но advanced там куча приложения может быть. и за каждым надо следить... а это уже сложнее

все равно что обслуживать сразу 5-7 приложений на симфе

у меня вот свой личный проект на yii2 в котором 6 доменов (прилоежний)

каждое приложение это отдельное приложения, нафига их загонять в одну, непонятно

у них много общего :)

база одна, а интерфейсы разные (админка, апи фронт для клиентов, главная странница с регой)

как бы это одно приложение, но с разными входными точками

ну и соответственно оформление, поведение и тд

это одно приложение, а не разные, так как они связаны

ну и входные должны быть одни

приложения нас только разнятся кодом. что их проще на подприлоежния разбить отдельные

у меня на симфони и админка и апи и фронт все через одну заходит, ве в одном бандле, и все вообще норм, у них у всех одинаковое поведение, а если оно различается, то все конфигурируется уже в коде

ок, а ентти у вас тоже разные? а сервисы все?

а конфиги им разные зачем?

я когда то так тоже делал) В итоге код приложения разростался до невероятных размеров

так же потом заказчик захотел разные страницы авторизации для каждой части

на бекенде одна форма и тема оформления, на фронте другая

ну да, а так то у тебя будет все маленькое) как будто у тебя количества кода станет меньше с такой структурой)

кароче все вырисовывалось в отдельные прилоежния работающие с одними данными

обоже

ну да, а так то у тебя будет все маленькое) как будто у тебя количества кода станет меньше с такой структурой)

не, кода не меньше а больше. Но обслуживать это стало на много проще.

это значит у тебя структура была не верная

у симфы же одна точка входа, один хэндлер ошибок 404 ,500 и тд. Верно?

ну с входом особых проблем нет, делаем новый контроллер, с той же формой, но другим темплейтом, и вуаля

ну да

а надо чтобы разные 404 были

на каждом домене свое оформления. соответсенно свои 404

нафига 404 для админки в другом оформлении?

а у етбя приложение на одном домене живет?

да, на одном

нафига 404 для админки в другом оформлении?

ну как нафига? чтобы соблюдать стиль поддомена.

у нам приложение на 6-ти поддоменах живет

у меня в админки 404 еще не было, по этому даже и не парюсь.

не проблема - 6 разных темплейтов для 404 и включай динамически

domain.com account.domain.com backend.domain.com dashboard.domain.com api.domain.com ...

ну в админке другие ошибки бывают, нет прав доступа. нет записи, ошибка системная и тд. Все же в админке шаблон купленный на themeforest.com а для фронта люди делают и рисуют персональный диз.

все равно не вижу сложностей

Так что пытаться что-то скрестить... не очень вариант :) но мы так делали раньше, опыт получили.

ERROR: S client not available

Да, я понимаю. Решением не проникнишься пока не столкнешься с проблеммой. Мы вот свою решили так. Ладно это не важно :)

в симфе можно бандл в бандле подключить?

слава б-гу нет

blog - profile account - profile dashboard - profile а не BlogProfileBundle AccountProfileBundle DashboardProfileBundle

а, понял.

У нас была похожая ситация, только мы наоборот собрали все в одно приложение, чем уменьшили дублирования кода, и получили более понятный и читаемый код.

зачем это делать отдельными бандлами? 0_0

потому что так требует бизнеслогика приложения.

бандлы вообще не для того(

ох епт

В блоге в профиле одни настройки. относящиеся к блгоге.

ну... ссорян. я могу не правильно трактовать зачем бандлы.

настройки к блогу? и что там за настройки?

кстати, а как правильно использовать бандлы?

В блоге в профиле одни настройки. относящиеся к блгоге.

разные папочки в папке Controller и все

+1

у AppBundle ?

да

кстати, а как правильно использовать бандлы?

http://symfony.com/doc/current/best_practices/index.html

главное что бы не появлялся волшебный CoreBundle с сущностями

ггг

во, коллеги. Скажите как сделать тогда правильно.

@fes0r это же главное)

Ситуация

разбить логику на независимые контексты

если не можешь - херач AppBundle и не парься (хотя всеравно стоит подумать)

есть приложения которое будет микросервисом для работы с внешними заказами - амазон, ебей и тд. Список сервисов может расширяться. То есть в приложении нужно реализовать один интерфейс который потом смогут реализовывать другие бандлы и подключатсья к проекту. Вопрос - где хранить эти общие абстрактные интферйсы и классы от которых потом будут наследоваться бандлы сервисов?

надеюсь понятно изложил задачу.

я как раз и хотел сделать CoreBundle в котором ядро

а остальные уже наследуются и реализуют конечный функционал. Но выше сказал так не делать... а как делать?

ну смотри, у тебя есть один контекст - внешние заказы

каждому внешнему сервису дарим по адаптеру для какого-то интерфейса