Artem
Artem
а на мастер они по месяцу доходить могут
Artem
но это ппц геморой!
Дмитрий
через ихменения в гите
Дмитрий
а база тупо дропается и достается из боя
Дмитрий
ну это более менее рабочая схема
Дмитрий
и ее применяют, что я описал ровные парни
Дмитрий
я же писал выше
Дмитрий
все каркасные изменения, не контентные вносятся сразу в бой
Artem
ибо сам я таким не занимался, а надо бы
Vitaly
Из обсуждения я понял, что быстрого и удобного способа не существует. Хотя крупные проекты как-то с этим справляются. Если говорить про Joomla, а вижу компонент:
1) В настройках указывается подключение к dev и prod базам.
2) По клику происходит их сравнение. Отличия показываются по таблицам разными цветами
3) Есть возможность указать для каждого отличия - переносить его или нет.
4) После проверки и указания всех переносимых отличий нажимает кнопку 2
5) База prod обновляется подтвержденными изменениями из DEV
6) Profit!
Во насочинял! Как вам?😊
Дмитрий
Дмитрий
как это делают крупные
Дмитрий
если работают с битриксом и джумлой
Дмитрий
мы работали с такими и знаем как они работают
Дмитрий
схему я описал
Дмитрий
инструменты под эту вырабатывтает каждый как хочет
Дмитрий
я не привязывал бы этот инструмент к джумле
Дмитрий
а отдельные независимые скрипты
Дмитрий
и такой инструмент вы офигеете писать
Дмитрий
если честно
Дмитрий
«Есть возможность указать для каждого отличия - переносить его или нет.»
Дмитрий
и тут такой пласт интересный открывается
Дмитрий
используется промежуточный этап
Дмитрий
который представляет собой master
Дмитрий
ставится по файлам изменения с дева, база уже вяс нужная пришла с боя
Дмитрий
дальше настриваиется и все такое что требутеся
Дмитрий
и потом master заливается этот промежучтоный
Дмитрий
после тестирования
Дмитрий
дропается база в деве
Vitaly
Речь не про код. Только про то, как синхронизироваться 2 базы и изменениями.
Дмитрий
и приходит с боя
Дмитрий
и ставится
Vitaly
Так в базе DEV могут быть изменения отновительно prod
Vitaly
Настройки, новые пункты меню и т.п.
Дмитрий
это контент
Дмитрий
которые ведется на бое
Дмитрий
просто не публикуется
Дмитрий
настройки дропнутся, да, на деве
Дмитрий
ну и пофиг
Дмитрий
это настраивается на промежуточном этапе конечном
Дмитрий
на stage перед продом
Дмитрий
может это не так гениально, зато надежно
Vitaly
Т.е. пришли к тому, что все изменения настроек, которые делаются на DEV'е, нужно в процессе делать и на PROD. Но так нельзя, поскольку некоторые настройки связаны с кодом, которого на PROD еще нет.
Дмитрий
ну значит не делаются, только на дев
Дмитрий
выставлять потом после синзронизации
Vitaly
Vitaly
Дмитрий
мы расписали все изменения на дев что нам нужно сразу, меняем каркас бд на бою
Дмитрий
и дропаем на деве и получаем с боя
Дмитрий
Дмитрий
инструмент что вы там описали, вы не напишите
Дмитрий
потому что там такой пласт синхронизации интересный и особоенности СУБД откироется
Дмитрий
что вы офигеете
Дмитрий
и стабильно это никогда работать не будет
Дмитрий
я описал стабильный способ, как делают большие компании
Vitaly
Дмитрий
Настройки? А почему и нет? Там не меняется база по каждому чиху
Vitaly
А теперь пройдемся по нашей любимой PROшке в этом плане. Вообще весело выходит. Там ведь разметка вся в базе.😊
Дмитрий
Да
Дмитрий
Мы тоже думали как делать
Дмитрий
Синхронизировать инструментом не получится
Дмитрий
Руками надо походить и делать
Дмитрий
Если надо внести изменения в страницы
Дмитрий
Новые страницы создаются на бое
Дмитрий
Но не публикуются
Dmitry
/цитата
Vitaly
Дмитрий
ну, приключение, ок
Дмитрий
я такое, пожалуй, пропущу
Vitaly
Конечно, там очень много тонкостей. Но даже если оно работало бы только для целых таблиц, а не их отдельных данных, это уже было бы отлично.
Vitaly
Но это всё пока только мечты. А в реальности будем, по-старинке, 🤲
Дмитрий
Дмитрий
?
Дмитрий
типа
Дмитрий
про промежуточный этап и все такое
Дмитрий
а этот компонент типа улучшение работы? 😀