Database DevOps у CI/CD: автоматизація міграцій БД без простоїв

Ми інтегруємо автоматизацію міграцій бази даних прямо у ваш CI/CD пайплайн, щоб кожна зміна схеми проходила через рев'ю, тестування та контрольований деплой. Забудьте про ручні ALTER TABLE у production — це ризик, який ми усуваємо. На практиці це означає: кожна міграція версіонується, проходить лінтинг SQL, виконується до деплою застосунку, і в разі помилки блокує реліз.

Наприклад, на одному з проєктів (PostgreSQL, 500 ГБ даних) команда застосовувала міграції вручну, що призвело до трьох інцидентів за квартал: двічі забули застосувати, один раз застосували двічі. Після впровадження автоматизації кількість інцидентів знизилася до нуля.

Чому міграції вручну небезпечні?

Ручне застосування міграцій — класичне джерело інцидентів: забули застосувати після деплою, застосували двічі, деплой відкотили, а міграцію ні. А ALTER TABLE orders ADD COLUMN discount_cents INT на 200 млн рядків займає 40 хвилин і блокує всі INSERT/UPDATE. Database DevOps вирішує ці проблеми: кожна міграція версіонована, ідемпотентна і проходить той самий пайплайн, що й код.

Як уникнути блокувань при масових DDL?

Для таблиць з мільйонами рядків стандартний ALTER TABLE небезпечний. Використовуйте:

• CONCURRENTLY для створення індексів (не блокує запис).
• pg_repack для реорганізації таблиць без простоїв.
• Backfill — поступове заповнення колонки з DEFAULT NULL з подальшим додаванням constraint.

Наприклад, додавання колонки status VARCHAR(16) на таблицю 100 млн рядків: без backfill — блокування на 30 хвилин, з backfill — нуль секунд.

Як забезпечити zero-downtime при міграціях?

Для таблиць з мільйонами рядків стандартні DDL можуть викликати тривалі блокування. Використовуйте CONCURRENTLY для індексів, pg_repack для реорганізації та backfill для додавання колонок. У PostgreSQL додавання колонки з DEFAULT NULL — миттєве, але без DEFAULT — блокування на повний перезапис таблиці. Для таблиць > 10 млн рядків використовуйте батчевий backfill: додаєте колонку як nullable, потім у фоні оновлюєте записи пачками і в кінці додаєте NOT NULL та DEFAULT. Це знижує блокування до мілісекунд. Flyway Documentation: Zero-downtime Migrations

Як ми автоматизуємо міграції в CI/CD

Ми налаштовуємо пайплайн з Flyway або Liquibase — залежно від вашого стеку. Міграції іменуються за шаблоном V{version}__{description}.sql (Flyway) або changeset (Liquibase).

1. Підготовка репозиторію: створюємо директорію db/migrations, визначаємо формат іменування.
2. Лінтинг SQL: підключаємо sqlfluff з правилами для PostgreSQL (L003, L010, L014).
3. Конфігурація секретів: додаємо змінні середовища DB_HOST, DB_USER, DB_PASSWORD у CI/CD.
4. Команда міграції: виконуємо flyway migrate з параметрами -connectRetries=10 та -validateOnMigrate=true.
5. Перевірка відкату: на staging тестуємо rollback до певної версії.

Порядок важливий: міграція виконується до деплою застосунку. Якщо вона впала — деплой не стартує. Приклад міграції Flyway:

-- V5__create_idx_orders_user_id.sql CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_user_id ON orders(user_id); 

Pipeline GitHub Actions з перевіркою та міграцією:

---
name: Database Migration
on:
  push:
    branches: [main]
jobs:
  lint-and-migrate:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Lint SQL
        run: |
          pip install sqlfluff
          sqlfluff lint db/migrations/ --dialect postgres --rules L003,L010,L014
      - name: Flyway migrate
        uses: docker://flyway/flyway:10-alpine
        with:
          args: >
            -url=jdbc:postgresql://${{ secrets.DB_HOST }}:5432/${{ secrets.DB_NAME }}
            -user=${{ secrets.DB_USER }}
            -password=${{ secrets.DB_PASSWORD }}
            -locations=filesystem:./db/migrations
            -connectRetries=10
            -validateOnMigrate=true
            -outOfOrder=false
            migrate

Аналогічно налаштовується в GitLab CI та Jenkins.

Порівняння Flyway vs Liquibase

Liquibase кращий за Flyway у підтримці rollback та multi-database: liquibase rollback --tag=v2.5.0 відкочує всі changeset'и до тегу.

Процес впровадження Database DevOps

Отримайте консультацію для оцінки вашого проєкту — наші інженери зв'яжуться з вами протягом дня.

Типові помилки та як їх уникнути

• Ніколи не редагуйте вже застосовані міграції. Тільки додавайте нові.
• Перед DROP TABLE робіть snapshot БД — це врятує при помилці.
• Для індексів на великих таблицях завжди використовуйте CONCURRENTLY.

Що входить в роботу

• Аудит поточних SQL-скриптів та схеми
• Розробка версіонованих міграцій для Flyway або Liquibase
• Налаштування CI/CD пайплайну (GitHub Actions, GitLab CI, Jenkins)
• Zero-downtime стратегія для великих таблиць (pg_repack, backfill)
• Документація по rollback та тестуванню
• Навчання команди (1 година)

Досвід наших інженерів — 5+ років, реалізовано понад 40 проєктів з автоматизації міграцій. Гарантуємо безпеку схеми та відсутність lock-конфліктів.

Строки

Базове налаштування займає від 2 до 4 днів. Якщо потрібна конвертація наявних SQL-скриптів у формат міграцій — до тижня. Вартість розраховується індивідуально. Пишіть — оцінимо ваш проєкт під ключ.

Зв'яжіться з нами для консультації по вашому проєкту — підберемо оптимальний інструмент і стратегію.