Comments 8
А в чем преимущество генерации SDK из SQL по сравнению с использованием ORM с поддержкой построения авто-миграций и генерации запросов?
Плюс как вы отслеживаете актуальность версии SDK: есть две команды, одна использует версию 1.0, вторая 1.1, выпускаете версию 1.2, в которой переименовываете табличку, а какой-то из клиентов все еще использует старое название?
Я насколько понял, этот инструмент покрывает кейс использования бд в нескольких сервисах. В целом вроде бы интересно.
Спасибо за вопросы!
А в чем преимущество генерации SDK из SQL по сравнению с использованием ORM с поддержкой построения авто-миграций и генерации запросов?
Как обеспечить обратную совместимость в авто-миграции ORM? Это то, что необходимо для бесшовных релизов и Continuous Deployment. Они должны быть такими, чтобы одновременно могла работать и старая и новая версия приложения.
Миграции через ORM усложняют деплой, если вы разворачиваете несколько инстансов приложения. Какой инстанс должен накатывать миграции?
ORM вас приковывает к одному языку программирования в качестве клиента. Иначе получите хаос в зависимостях. Например: ORM в Java имплицитно определяет схему БД, клиент БД на Python эту схему должен либо выводить из кода Java, либо из развёрнутой БД. Менять схему будет сверхдорого.
ORM ограничивает вас до примитивных запросов. Для серьёзного использования возможностей БД нужен доступ к SQL.
ORM забирает на себя контроль за производительность запросов. В нетривиальных случаях, как правило, это сбоит.
Плюс как вы отслеживаете актуальность версии SDK: есть две команды, одна использует версию 1.0, вторая 1.1, выпускаете версию 1.2, в которой переименовываете табличку, а какой-то из клиентов все еще использует старое название?
Сперва маленькая ремарка: версию 1.2 с переименованием таблицы я бы скорее назвал 2.0, квалифицируя это как обратно-несовместимое изменение по SemVer.
Озвученная вами проблема решается теми же способами, как в REST-API переход с /v1 на /v2. Если это внутри компании, то все пользователи вам должны быть известны и можно решить коммуникацией. Дать срок на переход и дождаться отмашки, что ребята готовы. Выкатывать переименование таблички, пока есть важные системы, к этому не готовые, конечно, нельзя.
Этот процесс возможно и автоматизировать различными способами. Можно, например, ввести реестр актуально используемых версий SDK, заполнять его в CI на стороне клиентов. Но звучит как overkill.
Можно косвенно мониторить актуальное использование по статистике скачиваний артефактов из какого-нибудь artifactory. В компаниях, где идёт активная разработка, как правило, актуальные артефакты скачиваются множество раз в день.
Отслеживание изменений в БД (схема и данные), хранение в version control system и поставка на production среду не проблема. Есть опыт использования разных продуктов и подходов.
Реальные сложности с откатом изменений.
У вас красивый Flow Diagram для накатки изменений.
А есть ли у вас такой же Flow Diagram для отката изменений с Production и восстановления предыдущей версии базы данных?
В целом же предлагают использовать обратносовместимые изменения при релизе. Поэтому по идее откатывать ничего не нужно. А есть какие нибудь инструменты с поддержкой отката?
А есть какие нибудь инструменты с поддержкой отката?
Есть инструменты, в которые заложена опция для отката на предыдущую версию, но сам код отката нужно писать вручную.
Откат - процедура сложная и в некоторых случаях невозможная.
Поэтому и поинтересовался, может у вас появилась волшебная идея.
Нашёл у liquibase и flyway в enterprise. Буду иметь ввиду. Но в целом конечно в автоматическом режиме выглядит конечно рискованно у liquibase.
Спасибо за вопрос!
Как вы сами заметили, процедура эта в некоторых случаях невозможна. Данные из удалённой таблицы откатом миграции не вернёшь. В чём тогда польза?
Я не вижу никакой, кроме способа для успокоения себя держать под рукой готовую миграцию, устраняющую последствия от накатываемой. Ну, если так уж сомневаетесь в конкретной миграции (настолько её не протестировали), держите такую миграцию наготове в MR/PR и замерджите и задеплойте через CD, если потребуется, как следующую миграцию. В большинстве же случаев вы сможете по факту написать необходимую миграцию, устраняющую последствия не многим медленнее.
Обременять разработку и автоматизацию необходимостью постоянно поддерживать обратный путь миграций, который, к тому же, мало кем полноценно тестируется, а применяется на деле практически никогда, кажется мне бессмысленным. Замечу, что я не один с таким мнением. Например, автор Postgraphile запилил альтернативный мигратор с такой же аргументацией.
Помимо сказанного замечу, что с проверками обратной совместимости, описанными в статье, вероятность наступления ситуаций, когда вам экстренно потребуется делать откат, снижается радикально.
Безопасный Continuous Deployment БД по принципам DB-First