Comments 62
рановато вы решили
symfony 3.3 вышел, а значит не рано. У меня схожие подходы уже больше года используются на проектах и я доволен.
Да по сути перевод давно начался, с релизом 3.2 примерно, если не раньше. parameters.yml очень неудобен для автоматического развертывания, а разные точки входа для прод и дев окружения очень неудобны при тестировании клиентов сервиса с симфони слабо связанными: задать через переменные окружения всё — идея, лежащая на поверхности.
У меня для для конструкций типа Route ("host": "sub.{domain}", "defaults": {"domain": "%env(DOMAIN)%"}, "requirements": {"domain": "%env(DOMAIN)%"}}) всё разрешалось в момент прогрева кэша, а не в рантайме.
Не эквивалентны по поведению неуказанная среда и APP_ENV=prod.
они разрешаются в compile-time (прогрева кеша), а не в рантайме.
как раз таки Cache Warmup это не совсем compile time, а скорее рантайм. То есть на момент компиляции роутов контейнер зависимостей уже скомпилен.
Хотелось бы пофиксить, может есть идеи?
У меня не вышло. Как минимум потому что часть того что прогревается все же требует рантайма. Есть как бы варианты… Например — отказаться от Dockerfile, то есть собрать контейнер, прогреть кэши и уже потом сделать docker commit и уже этот образ дистрибьютить. Но хз.
как раз таки Cache Warmup это не совсем compile time, а скорее рантайм. То есть на момент компиляции роутов контейнер зависимостей уже скомпилен.
Всё равно это компиляция, а не обработка запроса. Ну, если кэш в проде прогревать до начала поступления запросов.
Например — отказаться от Dockerfile, то есть собрать контейнер, прогреть кэши и уже потом сделать docker commit и уже этот образ дистрибьютить. Но хз.
Не имеет значения. Зафиксируются значения на момент прогрева, что нарушит концепцию "строим образ и деплоим в разных окружениях". Работает только прогрев кеша на момент запуска контейнера из образа в ENTRYPOINT и(или) CMD.
Поэтому полный переход на .env файлы весьма затруднителен.
посмотрите на это с другой стороны — как насчет минимизировать различия между окружением? Что бы у вас параметры вроде disable_delivery просто лежали себе в yaml файлике для определенного окружения и все, а подменялось только то что реально должно подменяться. Какой энвайрмент. креденшелы, токены и т.д.
А я всего лишь хотел уйти от поддержки parameters.yml.dist -> parameters.yml и остаться только на .env.dist -> .env файле. Но пока приходится поддерживать оба механизма конфигурации.
некоторые специфичные параметры в parameters.yam
он не нужен. Я предлагаю все различия окружения выносить в конфигурацию именно окружения (config_prod.yml к примеру). А parameters.yml — он не нужен.
К этому приходят почти все кто держит свое приложение в каком-либо контейнере.
все остальное можно разнести.
только два параметра
ну у меня еще есть всякие DB_HOST, DB_PASS, REDIS_HOST, ELASTICSEARCH_URL` и прочие штуки.
А что делать, если у нас три десятка разработчиков с разными параметрами (персональные окружения)?
Реальные переменные окружения предполагается использовать на stage, prod и т.п. серверах.
три десятка разработчиков с разными параметрами
Избавиться от "персонального окружения"? Если у вас 30 человек и у каждого свое окружение, которое отличается от продакшена — у меня возникают большие вопросы.
у нас есть, например, дебаг тулбар, который управляется через параметры, т.к не всем разработчикам (фронтам, например) он нужен. да и вообще окружение по умолчанию отличается тем, что в разработке используется dev режим по умолчанию, на контурах дальше — прод. но мне казалось, что это логичная разница с продом, иначе зачем вообще тогда dev режим
т.к не всем разработчикам (фронтам, например) он нужен.
export SYMFONY_ENV=stage
например. У меня к примеру фронтэндеры работают на своих стэйджинг серверах (не хотят они себе докер). Деплоят туда что им нам надо, и норм. Я там отключенным держу дебаг панель, но профайлер доступен на всякий случай.
у вас есть отдельный env в symfony?
Ну давайте думать какие окружения нам нужны:
- prod — продакшен.
- stage — сервера которые используют QA, фронтэнды, мобильщики, в том числе для e2e тестов. Они же используются для demo внутренних к примеру (а тут уже дизайнеры, аналитики и все желающие). Тут отличие от продакшена только в том что мы врубаем профайлер и частенько используем всякие мэйлкэтчеры. Но это как раз таки через env разруливается на уровне настроек SMTP сервера. А так различия с продакшеном минимальны.
- dev — локальная разработка, много всего накручено поверх stage. И для более удобной отладки, и в целом в силу ограничений инфраструктуры и работы с third-party сервисами.
- test — очень похоже на dev но ориентируется на приемочные тесты.
Как-то так. По итогу с таким подходом можно намного более уверенно говорить фразы вроде "локально работает".
На парочке проектов есть ситуации когда в конфиг заносятся например фича тоглы, которые не привязаны к окружению, это скорее просто часть конфигурации.
test — очень похоже на dev но ориентируется на приемочные тесты.
А отдельного env для юнитов нет? С моками и пр.
stage — сервера которые используют QA, фронтэнды, мобильщики, в том числе для e2e тестов.
Про фронтов — я правильно понял, что у вас бэк — это чистое API и фронты пишут отдельное приложение, поэтому им не нужны всякие тормозящие фичи типа автоматических перегенераций кэша, статики приложения и пр? Если так, то ваша позиция понятна, у вас немного другой кейс.
У нас более «классическое» приложение с рендером на стороне твига, и фронты технически пишут то же самое приложение что и бэки, поэтому в нашем случае вот такой выделенный stage env не нужен (точней может и нужен, но не в таком варианте). QA, мобильщики и пр. используют просто prod вариант развернутый на внутренних контурах
А отдельного env для юнитов нет? С моками и пр.
А с каких пор юнит тесты хоть как-то привязаны к окружению? Они на то и юнит что тестируют юниты изолировано от любой инфраструктуры. И как раз таки то что проходит границу модуля и предоставляет доступ к инфраструктуре мы и мокаем.
То есть нам не нужен ни контейнер, ни кернел. А вот интеграционные/приемочные тесты — тут уже нужно.
у вас бэк — это чистое API
именно так.
вот в этом месте я для себя пока не решил для себя. после того, как вы замокали инфраструктуру — ваши тесты не стали изолированными?
я пишу тесты так, чтобы мокать, но именно эти моки и определены в тестовом енве. эти же тесты без проблем запускаются и в dev, но они попытаются сходить в реальные сервисы, а не в замоканные
после того, как вы замокали инфраструктуру — ваши тесты не стали изолированными?
ну типа да. Вы как бы тестировать юнит тестами должны контракты объектов, а контракты зависимостей вы подменяете на требуемое от них поведение. Соответственно если ваши зависимости стабильнее тестируемого кода, и контракты хорошо протещены, то все хорошо.
и определены в тестовом енве.
если вы контейнер зависимостей юзаете — то это не юнит тесты. Это интеграционные тесты. А интеграционные тесты — это обман (то это не значит что они не нужны).
любое окружение, которое не продакшен отличается от него по определению. не все параметры, как уже сказано выше, можно переопределить через dotenv, так что parameters.yml остается необходимым инструментом в конфигурировании площадки.
понятно что структура самих конфигов совпадает, вопрос именно в безаппеляционом тезисе "parameters.yml — он не нужен"
Инициатива по стандартизации структуры PHP пакетов: https://github.com/php-pds/skeleton
навязывать папку src — это имхо что выкидывать psr-4. плохо ложится на концепцию монорепозиториев, которые потом делят на пакеты через subtree. при том, что у нас есть такая крутая вещь, как композер — описывать структуры файлов можно и в нем (где конфиги лежат, где сурсы итд)
Я согласен, что предложенная флексом структура весьма нелогичная, но она навязана рецепту, который будет встраиваться в ваше прилложение, но структура вашего пакета остается полностью произвольной. Т.е. рецепт — это в некотором смысле адаптер между пакетом и флексом
P.S. Тема очень глубокая с множеством точек зрения. Я согласен с вашими мыслями и сам пока еще не определился с какой я стороны.
Как вариант, в composer.json можно указывать переменные, переопределяющие стандартные пути, а в рецептах использовать плэйсхолдеры в путях "%app_src% и т. п.
Как я понимаю, основная проблема в web и etc вместо public и config? Вообще, посмотрев на начальные данные, сложилось впечатление, что Symfony очень сильно влияет на тренды именования и потому посое релиза в текущем виде тренды могут измениться.
А я бы вообще выбрал etc и www
Подействовала критика: http://fabien.potencier.org/symfony4-directory-structure-updates.html
Надо обновить пост :)
Symfony 4: структура приложения