и создаешь config_dev.yml

config_staging.yml

и у тебя будут подключаться нужные конфиги

Получается parameters_dev.yml надо еще создавать?

нет

в parametrs.yml ты можешь сказу указать все настройки

только с префиксом

Для всех сред?

да

Это общая практика? Или типа костыля

Удобнее было бы иметь parameters.dev.yml

ну вообще у тебя не должно в одной рабочей копии запускаться сразу разные среды ;)

эти среды будут на одном сервере?

по идее у тебя parametrs.yml должен быть один

и настройки одни

без префиксов

и для каждой среды ты можешь менять конфиг через config_env.yml

а если ты запускаешь несколько сред на одной машине то это уже не общая практика)

кстати, в симфони тебе надо не забыть создать app_dev.php, app_staging.php

и при инициализации указывать env в них

ну вообще у тебя не должно в одной рабочей копии запускаться сразу разные среды ;)

Я согласен, но это надо как-то обосновать

соответственно в nginx rewite на них так же должен быть настроен

Они просто так не сдадутся ;)

плять, пойду в issue клиента телеграмовского, просить фичу объеденения сообщений от одного человека

)))))

ты

точно

этого

хочешь? :)

Они просто так не сдадутся ;)

а зачем вам вообще куча окружений?

Ну.. затем зачем они и придуманы были

ну разделить дев, тест и продакшн ;)

Есть staging база которую можно ломать, есть ua база на которой уже проходят приемочные тесты, иногда с клиентами

А есть prod где все серьезно

и всё в пределах одного физического сервера ^_^

ну так разработчики же не свою копию в стейдж или ua запускают?

Ну манагер хочет допустим консольные команды запускать для dev, staging и ua с локала

менеджеру 3 ярлычка запускающие соответствующие ssh сессии и все ;)

Я понял щас какой можно аргумент привести - выполнение консольной команды над удаленной базой в другом кодовом окружении ведет к нарушению консистентности проекта в запускаемой среде ;)

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

а если уж очень нужно... может там какие-то команды сбора статистики или еще что, то можно решить обычным sudo

блин, я придумал гениальное решение, как застравить работать webpack —watch внутрях вирталбокса... настолько простое, что не понимаю, почему я раньше это не сделал...

и как?

всего-то нужно создать вотчер для шторма, который будет делать ssh vagrant — touch $file

Это общая практика? Или типа костыля

это нормальная практика потому что в symfony yaml шаблоны имеют наследование

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

по идее все среды должны быть идентичны проду

и разворачивать их надо рядом

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

Я имею в виду параметры подключения к БД например

менять только базу и юзера

@chebotarevp https://github.com/symfony/symfony-standard/tree/master/app/config видишь есть 3 файла config_dev.yml, config_test.yml, config_prod.yml ?

Я вижу, но я то спрашиваю про parameters.yml, который всегда один в папке лежит

И все три среды его читают

и чем это плохо?

Хотя...в принципе, зачем parameters то. Стейдж и приемочный тест и т.п. - там же одна база на всех, ее можно в соответствующий конфиг и все

Я вижу, но я то спрашиваю про parameters.yml, который всегда один в папке лежит

так сделай import нужного конфига в каждом из файлов

parameters нужен, что бы поддерживать разные конфигурации для разных рабочих копий

Можно. Но факт в том что этих parameters.yml требуется иметь больше чем один на одной разработческой машине

Можно их переименовывать впринципе

разработческая машина должна иметь только dev окружение

У тебя у каждого разработчика будет отдельная staging база?

У тебя у каждого разработчика будет отдельная staging база?

Нет у всех общие

Ну о том и речь, параметры подключения идут прямо в config_staging.yml

разработческая машина должна иметь только dev окружение

Ну должна то должна, но им хочется не так. И объяснить почему неправильно это хотеть - труднвато.

Ну о том и речь, параметры подключения идут прямо в config_staging.yml

Впринципе да, идея годная

Тогда остается только вопрос с теми параметрами которые секретны и не должны храниться в гите

ERROR: S client not available

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

Ну должна то должна, но им хочется не так. И объяснить почему неправильно это хотеть - труднвато.

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

Тогда остается только вопрос с теми параметрами которые секретны и не должны храниться в гите

тогда вопрос - а как "они" планируют распространять эти параметры по разработчикам в случае их изменения? Рассылкой в почте, "поменяйте все key в parameters_staging.yml"?

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

Ну например манагер хочет запускать команды на prod и на ua, а там разные базы и пароли к ним секретные

тогда вопрос - а как "они" планируют распространять эти параметры по разработчикам в случае их изменения? Рассылкой в почте, "поменяйте все key в parameters_staging.yml"?

Сейчас такое адище и происходит :D

Смотришь у тебя шторм перестал подключаться к базе стейджинга, идешь в слак и спрашиваешь "какого хрена?" Минут через 10 тебе отвечают что базу пересоздали и она теперь по другому адресу.

Ну просто ничего не объяснять ;) Если техлид - сказать, как будет. Если нет - сказать, что с командой, пилящий сук под собой во главе техлида тебе не по пути ;)

а как вы деплоите?

у нас в aws elastic beanstalk все работает

Ну просто ничего не объяснять ;) Если техлид - сказать, как будет. Если нет - сказать, что с командой, пилящий сук под собой во главе техлида тебе не по пути ;)

У нас сложно, все как-бы техлиды и демократия

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

кстати, ты же можешь подключить в конфиге не paramerts.yml, а paramerts_%kernel.environment%.yml

и в зависимости от того, какие будут использоваться окружения создавать файлы parameters_*.yml

Ну да этот вариант нравится больше чем все переменные префикосвать средой и скидывать в один файл

а func (string $a = null) мона в пхп? что-то запяматовал ;)

да

народ, задеплоил симфони на сервак. Чтобы запустить начальную страницу приходится вбивать сайт.ру/web/app.php Как сделать автоматическое перенаправление? Наверное с помощью htaccess это делается

?

а как ты локально делал?

php bin/console server:run и запускал на 127.0.0.1:8000

и не парился

входной файл app.php находится в папке web

и до этого ни разу не запускал на сервере пхп сайты?

у тебя сервер или шаред?

нет, никогда. Надо просто какое-то правило вбить в htaccess в корневой папке

у меня сервер

mod_rewrite возможно

а почему не настроить виртуальный хост сразу в web?)

Подскажите плз почему в mysql такой запрос лочит одинаковые строки и приводит к дедлоку. S1: UPDATE table SET index_2=0 WHERE index_1=100 AND index_2=1 S2: UPDATE table SET index_2=0 WHERE index_1=150 AND index_2=1 нужно комбинированный индекс сделать их этих двух?

myisam?

если да, то локов не избежать, если innodb, то это странно

innodb