Введение: «Так исторически сложилось»
Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.
А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.
Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.
Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.
Почему стандартные инструменты не сработали
Flyway и Liquibase — отличные инструменты. Однако они предполагают, что каждый разработчик вручную пишет и согласует SQL-миграции. Это прекрасно работает в мире микросервисов, но в нашей реальности — неработоспособно:
каждую неделю вносятся тысячи изменений в десятки баз;
над схемами одновременно работают десятки разработчиков;
изменения пересекаются, конфликтуют и зависят друг от друга через linked servers и cross-database связи.
Ожидать, что каждый после правок аккуратно воссоздаст их в виде корректной, упорядоченной и непротиворечивой миграции — значит обрекать процесс на провал. Люди бы теряли часы на отладку, забывали про зависимости, путали порядок выполнения — и в итоге просто возвращались к прямым правкам в production.
Я понял: если миграции требуют от разработчика дополнительных усилий, они не приживутся. Чтобы CI/CD заработал, генерация миграций должна быть автоматической, прозрачной и безопасной. Разработчикам нужен мощный ассистент. Только так можно сделать процесс устойчивым — а не демотивирующим.
Решение: SchemaFlow AI — платформа, а не просто скрипт
Я разработал SchemaFlow AI — enterprise-платформу, которая превращает хаос в управляемый workflow. Главная идея проста: разработчик делает то, что умеет — пишет SQL-код. А всё остальное берёт на себя система.
Как это работает — по шагам
1. Подключение в несколько кликов
Мы сделали всё максимально просто. Подключение базы к сервису, экспорт схемы, создание репозитория в GitLab и настройка пайплайнов — всё происходит за несколько кликов через мастер.
prepare и deploy уже готовы к работе. 2. Работа как обычно
Разработчик клонирует репозиторий и продолжает работать привычными средствами.
objects. 
3. AI генерирует миграцию
Как только в репозитории появляются коммиты с изменениями схемы, ответственный за выпуск запускает пайплайн prepare.
Этот пайплайн отправляет запрос в SchemaFlow AI, который автоматически анализирует разницу между текущей и целевой версиями схемы.
Процесс генерации миграции происходит в два этапа:
Планирование
SchemaFlow AI строит детальный план миграции: определяет все необходимые действия —CREATE,ALTER,DROP— с учётом зависимостей между объектами. Результат сохраняется в виде человекочитаемого документа:review/V{номер}_review.md.Этот файл служит основой для код-ревью: инженеры могут проверить логику изменений, убедиться в корректности порядка операций и оценить потенциальные риски — до выполнения любого SQL-кода.Генерация
На основе утверждённого плана SchemaFlow AI создаёт готовый SQL-скрипт миграции, совместимый с Flyway:flyway/sql/V{номер}__*.sql.Скрипт содержит команды в правильной последовательности, безопасен для применения и учитывает особенности MSSQL (включая работу с linked servers, схемами, зависимостями и т.д.).
Оба файла — и план, и скрипт — автоматически коммитятся обратно в репозиторий. Это обеспечивает полную прозрачность, воспроизводимость и соответствие принципам Database-as-Code и GitOps.
4. Ревью и деплой
Ответственный за миграцию проводит ревью файла миграции, в этом ему помогает review.md — с описанием изменений, рисками, рекомендациями.
Аналитика и контроль
Здесь — «непаханое поле»: всё ограничивается лишь вашей фантазией и потребностями бизнеса.
Почему это сработало: фокус на удобстве
Нет обучения: разработчику не нужно осваивать новые парадигмы — он работает как раньше.
Нет страха: система берёт на себя рутину и риски, связанные с зависимостями.
Нет хаоса: каждая миграция проходит ревью, версионируется и аудируется.
Команда не сопротивлялась, потому что ничего не потеряла — но получила контроль.
Заключение
Надеюсь, вам не было скучно — и, что ещё важнее, что эта статья окажется кому-то полезной и вызовет интерес.
Я занимаюсь MSSQL уже много лет в роли DBA, обожаю performance tuning, строю системы мониторинга и автоматизирую процессы. Последний год активно изучаю возможности ИИ и методы его применения в повседневной работе.
Если вам интересно — следующая статья будет про мой продукт AI QueryAnalyzer и о том, как он помогает командам находить проблемный код и оптимизировать запросы.
Спасибо за внимание! Если вы дочитали до сюда — я искренне надеюсь, что не зря потратил ваше время.
Комментарии (37)
debagger
23.01.2026 05:17Самое интересное осталось за кадром. На сколько я понял, план миграции и скрипт генерирует LLM.
Какая модель используется?
Каким образом формируется контекст?
camelarius
23.01.2026 05:17Вероятно AI это инициалы автора, а не то что вы подумали. Кликбейт. Ну может ревью выхлопа diff-ов чем то рисуется
apatkin Автор
23.01.2026 05:17Нет, так просто совпало) LLM как раз берет всю рутину на себя. Сервис локально держит свою версию репозитория, которая равна состоянию базы, получает список diff-ов которые произошли в Git и формирует T-SQL скрипт миграции со всеми изменениями. После этого, происходит деплой этого скрипта в базу.
alan008
23.01.2026 05:17Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
apatkin Автор
23.01.2026 05:17Простите, промахнулся и ответил не вам.
Что происходит под капотом - это целая тема для новой статьи. Если коротко, что в данный момент в своих проектах я использую qwen-code, это AI агент для терминала. Он имеет множество параметров, в том числе возможность прикреплять файлы к контексту. Другими словами, контекст передается в виде подготовленных файлов (инструкция+скрипты). Дальше происходит каскадная работа сразу нескольких агентов, каждый выполняет свою часть задачи.alan008
23.01.2026 05:17Стало чуть понятнее, но всё равно не до конца.
objects/dbo/Procedures/GetReport.sql
Вот этот файл откуда взялся? В систему контроля версий изначально выложен скрипт всех объектов базы?
apatkin Автор
23.01.2026 05:17Да, это происходит на этапе подключения базы. Сервис используя mssql-scripter получает скрипты всех объектов и структурирует их в папке objects.
debagger
23.01.2026 05:17я использую qwen-code
Используете облачную модель или локальную? Хватает размера контекста? Там наверно большой получается, схемы всех БД + скрипты + инструкции... Не "плывет" модель?
apatkin Автор
23.01.2026 05:17Qwen-code позволяет использовать облачную модель через консоль. Задача сначала разбивается на шаги и каждый шаг передается отдельному агенту. Те задачу выполняет сразу оркестр агентов, которыми управляет агент-дережор.
Tzimie
23.01.2026 05:17Очень интересно. Закинул своим. Единственное, от Management Studio на русском чуть не вырвало
n0wheremany
23.01.2026 05:17Если первоначально правили прод, то как появился diff файл, который сделал разраб - какими такими привычными средствами?
Самое важное то где...
Я не вижу удобного функционала, кроме как просле правок скачивать через Microsoft.SqlServer.Management.Smo.Scripter схему таблиц, функции, хранимки и тп в файлы и коммитить. Так есть лог + diff + git - ai. Вот этот коммит уже можно накатить на прод, если делить на прод и тест. Только вот всем и каждому не раздашь по песочнице.
apatkin Автор
23.01.2026 05:17Задача как раз и состояла в том, что-бы забрать права у разработчиков с продовых баз и запретить им вносить правки кроме как через CI/CD. Бонусом они получили полную версионность для всех объектов в БД.
alan008
Если скрипт изменения строит сама эта система, я не до конца понял, что находится в первичном коммите от человека, как описано изменение базы, чтобы на его основе система начала строить скрипт разницы с другими схемами?
apatkin Автор
Давайте объясню на примере. Допустим, разработчику нужно добавить новый столбец в таблицу. В классическом подходе с 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 выполнит на базе.
Таким образом, разработчик делает то, что умеет — пишет логику. А вся рутина — генерация, упорядочивание, проверка зависимостей, подготовка к ревью — ложится на систему. И это масштабируется даже при сотнях тысяч объектов и десятках разработчиков.
Botanegg
Если вам нужны сотни миграций бд в день - у вас, к сожалению, что-то не так
ychu
Так не надо делать, для этого есть Repeatable migrations https://documentation.red-gate.com/fd/repeatable-migrations-273973335.html .
Используя Repeatable migrations он именно этим и будет заниматься... )