Comments 37
Если скрипт изменения строит сама эта система, я не до конца понял, что находится в первичном коммите от человека, как описано изменение базы, чтобы на его основе система начала строить скрипт разницы с другими схемами?
Давайте объясню на примере. Допустим, разработчику нужно добавить новый столбец в таблицу. В классическом подходе с 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 выполнит на базе.
Таким образом, разработчик делает то, что умеет — пишет логику. А вся рутина — генерация, упорядочивание, проверка зависимостей, подготовка к ревью — ложится на систему. И это масштабируется даже при сотнях тысяч объектов и десятках разработчиков.
Если вам нужны сотни миграций бд в день - у вас, к сожалению, что-то не так
Но теперь представим, что нужно изменить хранимую процедуру. Тогда в файл миграции придётся вставить полный текст новой версии:
ALTER PROCEDURE ...и далее — весь код процедуры, который может занимать 1000+ строк. Для Git это просто новый файл, и в diff’е не видно, что именно изменилось. Чтобы понять разницу, тимлиду приходится вручную сравнивать старую и новую версию — брать объект из базы, брать новую версию, запускать сравнение. Это долго, утомительно и легко пропустить важное.
Так не надо делать, для этого есть Repeatable migrations https://documentation.red-gate.com/fd/repeatable-migrations-273973335.html .
Таким образом, разработчик делает то, что умеет — пишет логику.
Используя Repeatable migrations он именно этим и будет заниматься... )
Самое интересное осталось за кадром. На сколько я понял, план миграции и скрипт генерирует LLM.
Какая модель используется?
Каким образом формируется контекст?
Вероятно AI это инициалы автора, а не то что вы подумали. Кликбейт. Ну может ревью выхлопа diff-ов чем то рисуется
Нет, так просто совпало) LLM как раз берет всю рутину на себя. Сервис локально держит свою версию репозитория, которая равна состоянию базы, получает список diff-ов которые произошли в Git и формирует T-SQL скрипт миграции со всеми изменениями. После этого, происходит деплой этого скрипта в базу.
Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
Простите, промахнулся и ответил не вам.
Что происходит под капотом - это целая тема для новой статьи. Если коротко, что в данный момент в своих проектах я использую qwen-code, это AI агент для терминала. Он имеет множество параметров, в том числе возможность прикреплять файлы к контексту. Другими словами, контекст передается в виде подготовленных файлов (инструкция+скрипты). Дальше происходит каскадная работа сразу нескольких агентов, каждый выполняет свою часть задачи.
Стало чуть понятнее, но всё равно не до конца.
objects/dbo/Procedures/GetReport.sql
Вот этот файл откуда взялся? В систему контроля версий изначально выложен скрипт всех объектов базы?
я использую qwen-code
Используете облачную модель или локальную? Хватает размера контекста? Там наверно большой получается, схемы всех БД + скрипты + инструкции... Не "плывет" модель?
Очень интересно. Закинул своим. Единственное, от Management Studio на русском чуть не вырвало
Если первоначально правили прод, то как появился diff файл, который сделал разраб - какими такими привычными средствами?
Самое важное то где...
Я не вижу удобного функционала, кроме как просле правок скачивать через Microsoft.SqlServer.Management.Smo.Scripter схему таблиц, функции, хранимки и тп в файлы и коммитить. Так есть лог + diff + git - ai. Вот этот коммит уже можно накатить на прод, если делить на прод и тест. Только вот всем и каждому не раздашь по песочнице.
Если вам интересно — следующая статья будет про мой продукт AI QueryAnalyzer
Давайте пока на текущей теме остановимся. 😊 Есть пара++ вопросиков.
Ни слова не сказано про sqlproj. Или он тут не используется?
Прогоняются ли какие-то минимальные тесты? Хотя бы сам скрипт миграции на тестовой БД?
Умеет ли ваш SchemaFlow AI cоздавать revert миграции?
Бонусный вопрос: как в прод попадают данные, добавляемые руками (справочники, мэппинги, и иже с ними)?
PS: определитесь куда AI в названии продуктов добавляете, в начало или конец. #cоветсдивана
sqlproj в данном сервисе не применяется. В данной реализации не предусмотрен pipeline на stage, просто потому, что команда находится в процессе "эволюции" подхода к разработке и о тестовой среде еще не договорились, но разумеется это легко реализуется в данной схеме. Реализацию revert миграций мы пока поставили на паузу, обсудив с разработчиками, они пришли к выводу, что быстрее будет внести изменения просто следующей миграцией, а не откатывать все. Данные, которые требуется вносить руками вносятся руками) На это нет запретов, для чего-то есть специально предназначенные модули или простая заявка на выполнение скрипта.
Мы похожую ситуацию разрулили повышением модульности, организацией процессов и ddl логами.
Конечно команда разработки поменьше, но тоже много всякого и комиты почти все в прод.
Но я слабо представляю как тимлид будет разбираться в нашем коде настолько, чтобы имелась возможность добавить эффективности за счет его проверки. У нас много сложной логики и так быстро разбираться во всем сразу, достаточным образом чтобы улучшить эффективность наврятли выйдет. Возможно конечно, если он только этим и будет заниматься..
У любого деплоя должно быть имя фамилия и отчество) Тимлид на то и тимлид, что-бы быть ответственным за выкатываемые изменения, это скорее организационная составляющая нежели техническая часть процесса. DDL логи хорошо, но они позволяют понять кто уже сломал.
Наш процесс сейчас только на начале своего пути, перед деплоем в прод, миграции сначала будут тестироваться в stage окружении.
Почему вы создаете свой тул, вместо того, чтобы пользоваться хорошо работающими более 10 лет тулами от RedGate.
Разработчик меняет схему и обьекты в базе, схемы сравниваются, генерируется миграция, в git выгружается как схема так и миграции. Вы же упоминаете RedGate, почему не пользуетесь на полную мощь и изобретаете велосипед?
В какой момент RedGate Flyway генерирует миграцию, как выглядит эта миграция? Это пересоздание объектов или он так же обработает новые столбцы в таблицах, изменения триггера, а не пересоздание его вместе с таблицей? Переименование объектов и ли полей внутри таблицы? Возможно мы и изобрели велосипед, такое зачастую случается в наше работе, разве я не прав?)
Вы предлагаете новое решение, хочется видеть сравнение - какие у него преимущества по сравнению с существующим. Какие недостатки существующего решения вынудили вас разрабатывать свое.
Если мы говорим обо одном и том же.
То есть вы написали свое решение, потому что redgate не умеет определять изменения обьектов в базе sql server, не умеет генерить скрипты для обьектов, скрипты миграций, не умеет подгонять код скриптов под диалект конкретной версии sql server?
Грустно это, что сказать...
Ну дело в том что при использовании Repeatable migrations во Flaway не нужно "ручное написание скриптов", при внесении изменений в хранимые процедуры. Скрипты пишутся только для изменения схемы, а текст хранимой процедуры просто сохраняется как файл который начинается с R_ИмяХранимойПроцедуры.sql.
Да разработчик сам решает V_ -> для скрипта который меняет схему, R_ -> для текста хранимой процедуры, тяжело запутаться, если честно.
С идемпотентностью да, могут быть вопросы.
Не нужно ничего знать, открываете R_ИмяХранимойПроцедуры.sql. и вносите изменения.
Существует несколько способов заставить Repeatable migrations повторятся каждый раз, и не надо ничего знать о checksum
Аналитики нет, за риски не понял..))
Последнее сложно комментировать, но мне кажется что "из коробки" это будет работать только для ваших условий использования.
И вот еще вопрос, а как ваша система генерирует скрипт миграции если нужно добавить столбец NOT NULL, и обычным default не отделаешься, тоже "автоматически"?
Еще такой момент, в статье описывается миграция структуры базы, но так, как будто это пустая база, без данных. Что как правило нереально. В реальности при миграции структуры самое сложное - это что делать со старыми данными - куда их переливать, как конвертировать (если меняется тип/формат колонки) и т.д., а в описанной схеме про данные вообще ни слова.
Ну разве такие операции делаются ежедневно и под нагрузкой? На моей практике такие операции выполняются крайне редко, а если вам нужно изменить тип колонки для таблицы с миллиардом записей, то такие операции поручаются DBA и заранее планируются.
Я не писал ни про "ежедневно" ни про "под нагрузкой", я лишь имел в виду, что если какая-то система живет и эволюционирует (меняется структура базы и т.д.), то как правило эти изменения структуры надо накатывать на рабочие базы (в момент "апгрейда версий системы", а уж ежедневно или не ежедневно - это смотря как часто происходят такие апгрейды). Просто для меня из статьи было не понятно, зачем вообще менять структуру базы, если это не "продакшен база" с энным количеством рабочих данных. Так бы и писали тогда "механизм предназначен для синхронизации изменений схемы базы между несколькими разработчиками в процессе разработки системы до ввода её в практическую эксплуатацию". Я не то чтобы жалуюсь, просто описанное сильно отличается от моих use case'ов работы с продакшен базами.
Конечно такие изменения делаются под нагрузкой. А какие другие варианты? Только построение индексов по смигрированным данным может занимать сутки.
От прямых правок к CI/CD: как мы внедрили миграции MSSQL через GitLab при помощи ИИ