У нас в командах только один человек ответственен за деплой изменений в прод и у него задача, что-бы деплой прошел штатно. Делать, что-то или не делать в этом случае, он сам принимает решение. В любом случае, он убедится, что миграция была протестирована.
Не понятно просто что именно вы хотите. Если не хотите проверять миграции, которые вы накатываете на прод - не проверяйте. Если хотите проверять - проверяйте. Тем временем мы вполне успешно пользуемся системой, которая готовит миграции по 11 тысяч строк:
Миграция сгенерированная SchemaFlow
Которая успешно была сначала протестирована и залетела на прод.
Одно другому не мешает, уверяю, нет ничего сложного глазами пробежаться по подготовленному скрипту миграции, выкатить его на stage, а после теста на прод.
В какой момент RedGate Flyway генерирует миграцию, как выглядит эта миграция? Это пересоздание объектов или он так же обработает новые столбцы в таблицах, изменения триггера, а не пересоздание его вместе с таблицей? Переименование объектов и ли полей внутри таблицы? Возможно мы и изобрели велосипед, такое зачастую случается в наше работе, разве я не прав?)
Ну разве такие операции делаются ежедневно и под нагрузкой? На моей практике такие операции выполняются крайне редко, а если вам нужно изменить тип колонки для таблицы с миллиардом записей, то такие операции поручаются DBA и заранее планируются.
Qwen-code позволяет использовать облачную модель через консоль. Задача сначала разбивается на шаги и каждый шаг передается отдельному агенту. Те задачу выполняет сразу оркестр агентов, которыми управляет агент-дережор.
У любого деплоя должно быть имя фамилия и отчество) Тимлид на то и тимлид, что-бы быть ответственным за выкатываемые изменения, это скорее организационная составляющая нежели техническая часть процесса. DDL логи хорошо, но они позволяют понять кто уже сломал. Наш процесс сейчас только на начале своего пути, перед деплоем в прод, миграции сначала будут тестироваться в stage окружении.
sqlproj в данном сервисе не применяется. В данной реализации не предусмотрен pipeline на stage, просто потому, что команда находится в процессе "эволюции" подхода к разработке и о тестовой среде еще не договорились, но разумеется это легко реализуется в данной схеме. Реализацию revert миграций мы пока поставили на паузу, обсудив с разработчиками, они пришли к выводу, что быстрее будет внести изменения просто следующей миграцией, а не откатывать все. Данные, которые требуется вносить руками вносятся руками) На это нет запретов, для чего-то есть специально предназначенные модули или простая заявка на выполнение скрипта.
Давайте объясню на примере. Допустим, разработчику нужно добавить новый столбец в таблицу. В классическом подходе с Flyway он создаёт или редактирует файл миграции — например, V005__add_column.sql — и пишет туда просто ALTER TABLE ... ADD COLUMN. Всё понятно: тимлид видит этот файл, понимает, что добавляется столбец, апрувит — и обновление выкатывается. Пока всё работает.
Но теперь представим, что нужно изменить хранимую процедуру. Тогда в файл миграции придётся вставить полный текст новой версии: ALTER PROCEDURE ... и далее — весь код процедуры, который может занимать 1000+ строк. Для Git это просто новый файл, и в diff’е не видно, что именно изменилось. Чтобы понять разницу, тимлиду приходится вручную сравнивать старую и новую версию — брать объект из базы, брать новую версию, запускать сравнение. Это долго, утомительно и легко пропустить важное.
А если таких изменений — десятки или сотни в день, а разработчиков — десятки? Каждый из них должен не только внести правки в логику, но ещё и аккуратно воссоздать их в виде миграционного скрипта, соблюдая порядок, зависимости, учтя все нюансы. Он вынужден держать всё в голове и потом «переписывать» свои изменения в файл миграции — причём так, чтобы не конфликтовать с тем, что делают коллеги. Это крайне сложно и демотивирующе.
Именно эту проблему и решает SchemaFlow. Разработчик больше не работает с миграциями. Он просто правит файлы объектов — например, objects/dbo/Procedures/GetReport.sql — как обычные SQL-файлы. Git фиксирует реальные изменения: вот здесь добавлен JOIN, здесь удалён параметр, здесь исправлен фильтр. Всё видно в diff’е, как в любом другом коде.
В день деплоя тимлид запускает пайплайн prepare. Система сравнивает текущее состояние репозитория (которое отражает желаемую схему) с последним зафиксированным состоянием базы, выявляет точный список изменений, анализирует зависимости — включая cross-database и linked servers — и генерирует два файла:
— человекочитаемый отчёт для ревью: «Изменена процедура X: добавлен JOIN к Y, удалён параметр Z», — готовый SQL-скрипт миграции, который Flyway выполнит на базе.
Таким образом, разработчик делает то, что умеет — пишет логику. А вся рутина — генерация, упорядочивание, проверка зависимостей, подготовка к ревью — ложится на систему. И это масштабируется даже при сотнях тысяч объектов и десятках разработчиков.
Задача как раз и состояла в том, что-бы забрать права у разработчиков с продовых баз и запретить им вносить правки кроме как через CI/CD. Бонусом они получили полную версионность для всех объектов в БД.
Нет, так просто совпало) LLM как раз берет всю рутину на себя. Сервис локально держит свою версию репозитория, которая равна состоянию базы, получает список diff-ов которые произошли в Git и формирует T-SQL скрипт миграции со всеми изменениями. После этого, происходит деплой этого скрипта в базу.
Простите, промахнулся и ответил не вам. Что происходит под капотом - это целая тема для новой статьи. Если коротко, что в данный момент в своих проектах я использую qwen-code, это AI агент для терминала. Он имеет множество параметров, в том числе возможность прикреплять файлы к контексту. Другими словами, контекст передается в виде подготовленных файлов (инструкция+скрипты). Дальше происходит каскадная работа сразу нескольких агентов, каждый выполняет свою часть задачи.
Интересное решение, хотя первое, что мне пришло в голову - это использовать ключи. Собственно ключи для подобных целей и существуют, но не исключено, что иногда важнее данные быстро записать, нежели проверить всю цепочку правил перед записью, учитывая нагрузку OZON, не удивительно, что данные проверяются уже после вставки.
У нас в командах только один человек ответственен за деплой изменений в прод и у него задача, что-бы деплой прошел штатно. Делать, что-то или не делать в этом случае, он сам принимает решение. В любом случае, он убедится, что миграция была протестирована.
Не понятно просто что именно вы хотите. Если не хотите проверять миграции, которые вы накатываете на прод - не проверяйте. Если хотите проверять - проверяйте.
Тем временем мы вполне успешно пользуемся системой, которая готовит миграции по 11 тысяч строк:
Которая успешно была сначала протестирована и залетела на прод.
Одно другому не мешает, уверяю, нет ничего сложного глазами пробежаться по подготовленному скрипту миграции, выкатить его на stage, а после теста на прод.
Всегда нужно тестировать то, что выкатываем на прод.
Было бы отлично, если бы вы написали об этом аналогичную статью. Это было бы очень полезно!
Если мы говорим обо одном и том же.
В какой момент RedGate Flyway генерирует миграцию, как выглядит эта миграция? Это пересоздание объектов или он так же обработает новые столбцы в таблицах, изменения триггера, а не пересоздание его вместе с таблицей? Переименование объектов и ли полей внутри таблицы? Возможно мы и изобрели велосипед, такое зачастую случается в наше работе, разве я не прав?)
Ну разве такие операции делаются ежедневно и под нагрузкой? На моей практике такие операции выполняются крайне редко, а если вам нужно изменить тип колонки для таблицы с миллиардом записей, то такие операции поручаются DBA и заранее планируются.
Да, конечно, LLM отлично справляется с распознаванием таких операций.
Qwen-code позволяет использовать облачную модель через консоль. Задача сначала разбивается на шаги и каждый шаг передается отдельному агенту. Те задачу выполняет сразу оркестр агентов, которыми управляет агент-дережор.
У любого деплоя должно быть имя фамилия и отчество) Тимлид на то и тимлид, что-бы быть ответственным за выкатываемые изменения, это скорее организационная составляющая нежели техническая часть процесса. DDL логи хорошо, но они позволяют понять кто уже сломал.
Наш процесс сейчас только на начале своего пути, перед деплоем в прод, миграции сначала будут тестироваться в stage окружении.
Простите, первый опыт.
sqlproj в данном сервисе не применяется. В данной реализации не предусмотрен pipeline на stage, просто потому, что команда находится в процессе "эволюции" подхода к разработке и о тестовой среде еще не договорились, но разумеется это легко реализуется в данной схеме. Реализацию revert миграций мы пока поставили на паузу, обсудив с разработчиками, они пришли к выводу, что быстрее будет внести изменения просто следующей миграцией, а не откатывать все. Данные, которые требуется вносить руками вносятся руками) На это нет запретов, для чего-то есть специально предназначенные модули или простая заявка на выполнение скрипта.
Да, это происходит на этапе подключения базы. Сервис используя mssql-scripter получает скрипты всех объектов и структурирует их в папке objects.
Давайте объясню на примере. Допустим, разработчику нужно добавить новый столбец в таблицу. В классическом подходе с Flyway он создаёт или редактирует файл миграции — например, V005__add_column.sql — и пишет туда просто
ALTER TABLE ... ADD COLUMN. Всё понятно: тимлид видит этот файл, понимает, что добавляется столбец, апрувит — и обновление выкатывается. Пока всё работает.Но теперь представим, что нужно изменить хранимую процедуру. Тогда в файл миграции придётся вставить полный текст новой версии:
ALTER PROCEDURE ...и далее — весь код процедуры, который может занимать 1000+ строк. Для Git это просто новый файл, и в diff’е не видно, что именно изменилось. Чтобы понять разницу, тимлиду приходится вручную сравнивать старую и новую версию — брать объект из базы, брать новую версию, запускать сравнение. Это долго, утомительно и легко пропустить важное.А если таких изменений — десятки или сотни в день, а разработчиков — десятки? Каждый из них должен не только внести правки в логику, но ещё и аккуратно воссоздать их в виде миграционного скрипта, соблюдая порядок, зависимости, учтя все нюансы. Он вынужден держать всё в голове и потом «переписывать» свои изменения в файл миграции — причём так, чтобы не конфликтовать с тем, что делают коллеги. Это крайне сложно и демотивирующе.
Именно эту проблему и решает SchemaFlow. Разработчик больше не работает с миграциями. Он просто правит файлы объектов — например,
objects/dbo/Procedures/GetReport.sql— как обычные SQL-файлы. Git фиксирует реальные изменения: вот здесь добавлен JOIN, здесь удалён параметр, здесь исправлен фильтр. Всё видно в diff’е, как в любом другом коде.В день деплоя тимлид запускает пайплайн
prepare. Система сравнивает текущее состояние репозитория (которое отражает желаемую схему) с последним зафиксированным состоянием базы, выявляет точный список изменений, анализирует зависимости — включая cross-database и linked servers — и генерирует два файла:— человекочитаемый отчёт для ревью: «Изменена процедура X: добавлен JOIN к Y, удалён параметр Z»,
— готовый SQL-скрипт миграции, который Flyway выполнит на базе.
Таким образом, разработчик делает то, что умеет — пишет логику. А вся рутина — генерация, упорядочивание, проверка зависимостей, подготовка к ревью — ложится на систему. И это масштабируется даже при сотнях тысяч объектов и десятках разработчиков.
Задача как раз и состояла в том, что-бы забрать права у разработчиков с продовых баз и запретить им вносить правки кроме как через CI/CD. Бонусом они получили полную версионность для всех объектов в БД.
Нет, так просто совпало) LLM как раз берет всю рутину на себя. Сервис локально держит свою версию репозитория, которая равна состоянию базы, получает список diff-ов которые произошли в Git и формирует T-SQL скрипт миграции со всеми изменениями. После этого, происходит деплой этого скрипта в базу.
Простите, промахнулся и ответил не вам.
Что происходит под капотом - это целая тема для новой статьи. Если коротко, что в данный момент в своих проектах я использую qwen-code, это AI агент для терминала. Он имеет множество параметров, в том числе возможность прикреплять файлы к контексту. Другими словами, контекст передается в виде подготовленных файлов (инструкция+скрипты). Дальше происходит каскадная работа сразу нескольких агентов, каждый выполняет свою часть задачи.
Такой громкий заголовок, а в статье ничего полезного нет.
Интересное решение, хотя первое, что мне пришло в голову - это использовать ключи. Собственно ключи для подобных целей и существуют, но не исключено, что иногда важнее данные быстро записать, нежели проверить всю цепочку правил перед записью, учитывая нагрузку OZON, не удивительно, что данные проверяются уже после вставки.