Я идейно с вами согласен. Парсинг очень хочется. Только вот, написание такого функционала - долго и дорого (во всяком случае, для меня). Ну и, чем больше СУБД (читай, диалектов SQL) тем еще сложнее.
Я в статье описал ролевой состав. Можете прикинуть количество людей=) Наш подход к разработке и автоматизации наоборот построен на принципе "разработчик ЛУЧШЕ знает, что он хочет". Ограничения мы вводим только там, где без них нельзя обойтись.
Касательно смены движка - для нас это просто еще один драйвер. Основной кост на смену движка в освоении нового диалекта и нюансов СУБД разработчиком.
Круто, что у вас это реализовано. Нам пришлось повозиться с т.з. стандартов в первую очередь.
К данным, я так понимаю, вопрос к DML, т.е. к конкретным значениям. Естественно мы не храним инсертов на 6,5ПБ в гите - это было бы странно. Мы храним DDL и DML в качестве датафиксов, либо инициализирующий загрузки таблицы. В гите у нас так же обвязка - в виде ETL. Это все к тому: 1) Откат для нас = накат нового альтера. Этот сценарий разработчик может приложить к поставке. 2) При откатах мы откатываем всю обвязку в т.ч. ETL (который знает про структуру таблицы нужной версии).
В целом, на практике, дешевле просто откатить DDL и перелить данные заново, просто запустив ETL соответствующей версии. Само-собой, технически, мы можем воссоздать объект "с-начала-времен", или откатить структуру таблиц, но обычно это штучные кейсы, когда встречается таблица с очень большим объемом данных.
Я надеюсь, ответил на вопрос. Если нет - можем продолжить тут или в телеге по желанию.
На оба вопроса — пока нет. Но upscale есть в планах. Думаю, что проблемы будут с балансировщиком между masters, т.к. в конфигурации single master его нет.
Еще дополню, раз в планах есть — fabric8. Деплоится на OpenShift, kubernetes и miniShift. Разворачиваются нэймспейсы с набором утилит cd-pipeline, сразу три окружения типа test-staging-prod.
А не пробовали смотреть в сторону кластеризации/оркестрации типа kubernetes и openshift? Не нужно было бы заморачиваться с вводом новых ВМ, сетью на уровне docker. Для каждого дева свой namespace, поддомен и т.д. да и деплой из Гита есть из коробки.
Далеко не все пользуются облачными провайдерами. Да и исходя из контекста я имел ввиду скорее пайплайно-строение, секреты, знания триггеров и т.п.
Я идейно с вами согласен. Парсинг очень хочется. Только вот, написание такого функционала - долго и дорого (во всяком случае, для меня). Ну и, чем больше СУБД (читай, диалектов SQL) тем еще сложнее.
Я в статье описал ролевой состав. Можете прикинуть количество людей=) Наш подход к разработке и автоматизации наоборот построен на принципе "разработчик ЛУЧШЕ знает, что он хочет". Ограничения мы вводим только там, где без них нельзя обойтись.
Касательно смены движка - для нас это просто еще один драйвер. Основной кост на смену движка в освоении нового диалекта и нюансов СУБД разработчиком.
Круто, что у вас это реализовано. Нам пришлось повозиться с т.з. стандартов в первую очередь.
К данным, я так понимаю, вопрос к DML, т.е. к конкретным значениям. Естественно мы не храним инсертов на 6,5ПБ в гите - это было бы странно. Мы храним DDL и DML в качестве датафиксов, либо инициализирующий загрузки таблицы. В гите у нас так же обвязка - в виде ETL. Это все к тому: 1) Откат для нас = накат нового альтера. Этот сценарий разработчик может приложить к поставке. 2) При откатах мы откатываем всю обвязку в т.ч. ETL (который знает про структуру таблицы нужной версии).
В целом, на практике, дешевле просто откатить DDL и перелить данные заново, просто запустив ETL соответствующей версии. Само-собой, технически, мы можем воссоздать объект "с-начала-времен", или откатить структуру таблиц, но обычно это штучные кейсы, когда встречается таблица с очень большим объемом данных.
Я надеюсь, ответил на вопрос. Если нет - можем продолжить тут или в телеге по желанию.