Знакомая история: разработчик накатил миграцию в тестовую среду, всё упало, а DBA узнает об этом последним. В обычной разработке мы привыкли к код-ревью и CI/CD пайплайнам, но базы данных часто остаются «вещью в себе». Изменения в схемах таблиц часто делаются руками через консоль или в лучшем случае через Liquibase, который не дает нормального визуального контроля.

Недавно наткнулся на Bytebase. Это Open Source проект, который пытается превратить управление базами данных в нечто похожее на работу с Git. Ребята попали в CNCF Landscape, и это уже серьезный звоночек, что перед нами не просто очередная обертка над SQL-клиентом.

Что это вообще такое

Если коротко, Bytebase — это веб-платформа для совместной работы над БД. Она объединяет в себе графический интерфейс для запросов (как в DBeaver), систему контроля версий для схем и полноценный цикл одобрения изменений. Вместо того чтобы перекидываться SQL-файлами в Slack, команда создает тикет в Bytebase, проходит проверку линтером и получает «ок» от старшего коллеги.

Проект написан на Go, работает быстро и поддерживает почти всё, что мы используем в проде: PostgreSQL, MySQL, MongoDB, Redis, Snowflake и даже ClickHouse.

Чем Bytebase может упростить жизнь

Когда я впервые открыл проект, меня зацепило то, как они реализовали GitOps. Вы подключаете свой репозиторий на GitHub или GitLab, и проект начинает следить за папкой с миграциями. Как только вы пушите новый SQL-файл, Bytebase автоматически создает задачу на изменение в нужной базе.

SQL Review — это отдельная песня. В системе встроено около 200 правил. Например, можно запретить создание таблиц без первичного ключа или ограничить использование DROP TABLE. Линтер проверяет код еще на этапе создания черновика, что экономит кучу времени тем, кто обычно эти миграции ревьюит.

Для безопасности тут тоже нашлось место. Есть маскирование данных: можно настроить права так, чтобы разработчик видел в результатах запроса **** вместо реальных email-адресов или телефонов пользователей. При этом DBA видит чистые данные. Это гораздо удобнее, чем плодить копии баз с «затертыми» данными для локальной разработки.

Интересная фишка — Drift Detection. Bytebase умеет проверять, не изменил ли кто-то схему базы в обход системы. Если какой-нибудь админ ночью зашел в консоль и тихо добавил индекс, система это подсветит. Это избавляет от сюрпризов, когда локальные миграции не накатываются на прод из-за расхождений в структуре.

Как попробовать в деле

Разворачивается всё одной командой в Docker. Для экспериментов этого более чем достаточно:

docker run --init \
  --name bytebase \
  --publish 8080:8080 \
  --volume ~/.bytebase/data:/var/opt/bytebase \
  bytebase/bytebase:latest

После запуска на localhost:8080 вас встретит мастер настройки. Можно сразу подключить какую-нибудь тестовую базу PostgreSQL или MySQL и посмотреть, как работает визуальный редактор. Он, кстати, вполне заменяет тяжеловесные IDE, если нужно быстро поправить данные или глянуть структуру.

Технический стек и расширяемость

Backend написан на Go, а Frontend на Vue.js. Архитектура позволяет докидывать свои правила для проверки SQL и интегрировать инструмент в существующий Terraform-пайплайн. У проекта есть свой Terraform provider, так что управлять ресурсами Bytebase (проектами, пользователями, подключениями) можно как обычным кодом. Это удобно, если у вас сотни баз и настраивать каждую руками через веб-морду — сомнительное удовольствие.

Кому это пригодится

Bytebase точно не нужен, если у вас один проект с одной базой, где вы сами себе и разработчик, и DBA. Но если в команде больше пяти человек и проект активно растет, инструмент закроет много проблем.

Особенно он будет полезен:

1. Командам, которые хотят уйти от ручного выполнения SQL-скриптов на проде.
2. Тем, кто живет в мире микросервисов, где баз много и за всеми нужно следить.
3. Компаниям с жестким комплаенсом, где каждый чих в базе должен быть логирован и одобрен.

На мой взгляд, самое ценное здесь — прозрачность. Когда любой член команды может зайти и увидеть историю изменений конкретной таблицы, кто их инициировал и зачем, количество «ой, я что-то нажал и всё исчезло» падает до минимума.

Потыкать проект вживую можно на их демо-стенде, это быстрее, чем разворачивать у себя. Но если решите внедрять, заложите время на обучение команды — концепция Database CI/CD требует привыкания.