> Если вы заранее знаете, что структура у вас всегда будет меняться примерно одинаково, можете и автоматизировать. Но тогда не было бы такого вопроса.
Я допускаю, что в 95% случаев изменения в структуре будут следующими:
- добавить новую таблицу - очевидно, с этим проблем нет никаких, но это всё ещё подпадает в категорию "изменение структуры";
- добавить (именно добавить) в поле типа enum новое значение - с этим тоже никаких проблем;
- добавить колонку в таблицу среднего размера (100к строк) - это уже какой-то даунтайм на выполнение alter, но тоже не очень сложно звучит;
Поэтому мне и было интересно, как все эти случаи - разные между собой в деталях, но одинаковые по сути - уживаются в "правильном" процессе ci/cd. Чтобы понять для себя принцип, как строить процесс для разных ситуаций с базой.
> В правильном CI/CD таких изменений быть не должно
Не совсем понимаю этот ответ. То есть, я написал один раз структуру БД - и всё, никогда больше в жизни нельзя её править в процессе разработки?
> DevOps как культура как раз и говорит, что надо менять подход к работе
Я ж и спрашиваю, какой правильный подход для случая, когда мне надо изменить что-то в структуре БД, что будет сопровождаться даунтаймом всего сервера БД.
Если вписать pt-online-schema-change в какой-нить ансибл/дженкинс - это неправильный подход, то как тогда делают?
У меня откуда-то в голове взялась аксиома, что я не могу в докер-контейнере с базой делать "мелкие" операции, могу либо всё, либо ничего. Сейчас после вашего ответа я-то понимаю, что это глупость какая-то, и мне нет разницы - слать в него SELECT * FROM из пхп или ALTER TABLE из pt-online-schema-change. ¯\_(ツ)_/¯
Спасибо.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
А как это реализуется в случае того же скрипта в Github Actions, например?