Как тестировать нововведения на сайте?

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

Ты ответил

?!! Где?

Ты уже юлишь, впрочем, это даже не удивляет(с).

дамп, частями.. Наслушался умных слов, а сути не понимаешь.

Ок. Думаю ты опять спутаешь вход с входом, но я попробую. 

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

Красава.. Просто красава.. речь у него шла "об изменениях в базе"..

Ох ты ж и перевёртыш... Противно просто с такими общаться. Нафик тебя.

😂

Про "изменения" читай с первого поста. Я просто забыл, что ты много букв не читаешь, а надо бы. В этом вся суть.

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

Дальше без комментариев твоих постов, ибо я считал тебя более осведомленным за пределами стандартных задач ВП. Смысла говорить с тобой о том, что ты не использовал на практике и для конкретных задач - никакого.

Вот ты не поверишь - то что для тебя "понтануться", для меня суровая обыденность. Без этого воркфлоу мой код вообще никуда не попадет. Я вообще считаю неважно, пишешь ты лэндинг или высоконагруженный сайт. Подход должен быть один. Ошибки нужно отлавливать как можно раньше, для этого и существует много уровней проверок. А вот от этого -  "Х****к,  х***к и в продакшен" нужно отходить максимально, меньше проблем и в будущем.

Все давно придумано, для этого достаточно гитхаба/гитлаба и CI/CD - для кода + простейший скрипт для базы

Челик, когда ты спикаешь на этой лингве, мне хардово вотнится задемандить "не факайте мой брейн!!!"

Ферштейн, вердаммт швайнехунд?

Это как раз и будет

Говорить за сериализванные данные я тебе уже устал. Создаётся впечатление что это для тебя звучит также как "синхрофазотрон" для средневекового рыцаря  - страшно и непонятно. Поэтому ты тупо игнорируешь это факт.

И да. Не забывай русский - пригодится.

Уже смишно. "А мужики-то и не знали" и написали целый Liquibase зачем-то... Чисто для развития - "простейший" будет делать дампы данных и сруктуры, а потом разворачивать их (при озвученных объемах) зело небыстро

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

Если мы говорим о тестировании какого-то ux решения, то проще на сайте предусмотреть механизмы a/b тестирования, причем делать это надо по определенным сегментам.

Похоже все пошло в обсуждении не туда из-за неполной информации от ТС - зачем ему полная база.

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

Зачем мне иметь базу из 10000 записей, категорий, кастомов? Когда достаточно просто иметь то, над чем работаешь в данный момент и за глаза хватит 10 по теме разработки.

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