Типа sync

Нет

Нельзя

Насколько я помню

А если https://www.itefix.net/cwrsync ?

Не будет он новые файлы грузить. В том-то и проблема

Под мастдай что порекомендуете чтобы синкать директорию с сервером по sftp/ftp/прочему?

ну костыльный у вас флоу на самом деле

настрадаетесь с ним ещё

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

Хотя, грузить что-то "обратно" с production-сервака, штука, конечно, неприятная.

особенно если файло, которое тянешь с сервака перетирает твоё

жесть, в общем

а ты этот файлик на 3000 строк с самого утра отрастил до 5000 :(

Это да, решение спорное, но каков выход ("красивый", конечно) , например, если нужно то, что сотрудники заказчика льют сами вручную через админку на прод - у себя на деве иметь?

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

Это да, решение спорное, но каков выход ("красивый", конечно) , например, если нужно то, что сотрудники заказчика льют сами вручную через админку на прод - у себя на деве иметь?

Вот вот. Какой нафиг гит

Короче, надо что-то менять в этой жизни. Примаунтю локально директорию и буду в ней писать. Вопрос чем.

Нет-нет, никакого git. Git там идеологически не подойдет. К тому же, можно упариться лить в него "тонны" каких-нибудь "закрытых" медиа или документов, которые заказчик, как "супер-пупер-секрутную-информацию" ни в какую не хочет выкладывать хоть куда-то в паблик (например, не позволяет отдавать через cdn).

Двачую

значит для этого файла нужна своя файлопомойка

Там 2 вопроса: "чем примаунтить? (т.е. чем раздать) и "чем писать?"

а в сорсы нефиг совать бинарники

ладно

Достаточно просто выяснить, чем примаунтить.

Согласен, я и не предлагаю в сорцы бинарники совать. Просто, решений может быть несколько (и у каждого есть свои минусы и гиморои).

Хрен с ним, из под подсистемы линух сделаю

Там просто производительность низкая, они не допилили толком

Согласен, я и не предлагаю в сорцы бинарники совать. Просто, решений может быть несколько (и у каждого есть свои минусы и гиморои).

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

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

Не всегда есть ресурс пилить свой cdn. Заказчик, порой, не согласен ни на дополнительный сервер под медиа, ни на финансирование своего cdn, ни на аенду мощностей на внешнем сервере. Порой требования бывают довольно чуднЫми. Насчет людей с правами писать в сорцы - это да; решение по синканию файлов будет накладывать ограничение на доступ, но это так всегда: в чем-то плюс, в чем-то минус.

Не всегда есть ресурс пилить свой cdn. Заказчик, порой, не согласен ни на дополнительный сервер под медиа, ни на финансирование своего cdn, ни на аенду мощностей на внешнем сервере. Порой требования бывают довольно чуднЫми. Насчет людей с правами писать в сорцы - это да; решение по синканию файлов будет накладывать ограничение на доступ, но это так всегда: в чем-то плюс, в чем-то минус.

cdn?

че?

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

у меня другой вопрос.... на нормальный флоу работы доп расходы нужны в размере 10-20 баксов в месяц

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

че?

А что не так? Этим термином можно назвать решение любого масштаба, начиная с "один доп. сервак в углу" - заканчивая системой серваков, которая, такИ да, по определению, раскидана по разным гео-локациям, имеет оптимизацию доставки контента по региону и т.д.

а потом подняли, настроили, всё работает, никто не жалуется ну и збс

А что не так? Этим термином можно назвать решение любого масштаба, начиная с "один доп. сервак в углу" - заканчивая системой серваков, которая, такИ да, по определению, раскидана по разным гео-локациям, имеет оптимизацию доставки контента по региону и т.д.

CDN = Content Delivery Network. Причем тут тема?

> имеет оптимизацию доставки контента по региону и т.д. причем тут CDN?

мы ж про деплой

CDN готовый ты ж будешь юзать. ты ж не совсем наркоман, и то если тебе он нужен

да и это для статики

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

либо я вообще потерял нить разговора и это оффтоп

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

ну вот - разделить сборку и деплой

и извлекать из сорсов его никто не собирается

вжух и нет проблем

короч, ребят

давайте по существу

а то тут уже какой-то цикр начался

CDN-ы какие-то

которые как-то связаны с правками исходников на серваках

по существу - ничего не происходит :)

если по тематике канала - тишина полнейшая))

Есть ли готовое решение чтобы ограничивать миграции только для определенных хостов?

конкретизируй вопрос

чтоб в зависимости от hostname миграции либо запускались или нет?

Ну я например деплою приложение для 2 разных клиентов. И иногда миграции меняют не схему а данные. И чтобы указывать что вот эта миграция только вот для этих клиентов.

Или вообще есть что-то более разумное?

под клиентом подразумевается какая-то сущность и бизнес-логике?

Нет. Реальный человек пользователь.

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

Верно. Два инстанса.

Я думал реализовать интерфейс, который определяет метод типа forInstancesOnly(): array

И у каждого инстанса имя в .env

Метод возвращает список инстансов для которых миграцию выполнять.

ERROR: S client not available

та раздели папки с миграциями по проектам

Ну то есть руками копировать при разработке?

Ну я например деплою приложение для 2 разных клиентов. И иногда миграции меняют не схему а данные. И чтобы указывать что вот эта миграция только вот для этих клиентов.

разные энтити менеджеры делай

надо иногда и общие?

надо иногда и общие?

Чаще всего будут общие.

Но иногда в миграциях меняешь данные специфичные только для одного клиента.

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

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

так в миграциях же есть что-то типа $this->skipIf()

единственный вариант разделить управление схемой - разные энтити менеджеры

так в миграциях же есть что-то типа $this->skipIf()

это сделает их зависимыми от рантайма что плохо

единственный вариант разделить управление схемой - разные энтити менеджеры

Через конфигурации?

и там пишешь $this->skipIf(gethostname() != 'megaserver')

Через конфигурации?

да. Ну и еще один вариант - воспринимать все как одну схему

Я просто хотел миграции импрувнуть. :)

так в миграциях же есть что-то типа $this->skipIf()

хотя... можно и так....

Я просто хотел миграции импрувнуть. :)

я не думаю что у тебя проблемы с миграциями) так что лучше чего другое импрувни

я не думаю что у тебя проблемы с миграциями) так что лучше чего другое импрувни

Ну вот я сейчас и думаю как лучше реализовать. Это ещё не сделано.

https://stackoverflow.com/questions/6844153/migrating-multiple-databases-using-doctrine2-with-symfony2

ну вот что-то типа такого

одно приложение - одна схема

что тут сложного то?)

к имени базы привязываешься

к имени базы привязываешься

у имени "менеджера"

ну по сути - к имени клиента

одно приложение - одна схема

Схема не меняется, как я и сказал.

Это только для данных актуально.

ну по сути - к имени клиента

к имени менеджера

Это только для данных актуально.

ммм а это точно миграции? может у тебя под видом мигграций какой-нибудь импорт данных приложения идет?

к имени менеджера

имена менеджеров будут разными у разных заказчиков

к что по сути - к имени заказчика)

или к имени хоста