DBAtlas · Veritabanı operasyon atlası

Şema migration CI/CD (Flyway/Liquibase)

Belirti

Amaç: Veritabanı şema değişikliklerini versiyonlu migration dosyalarıyla yönet; Flyway veya Liquibase ile CI/CD içinde otomatik ama kontrollü uygula.

1. Versiyonlu migration dosyaları oluştur (Vxxx__ad.sql)

Her şema değişikliğini artan sürüm numaralı, adlandırılmış bir dosyaya yaz; Flyway kuralı V<versiyon>__<açıklama>.sql biçimindedir (örn. V1__ilk_semalar.sql, V2__siparis_tablosu.sql). Bu dosyalar Git'te tutulur ve sıra numarasına göre uygulanır. Uygulanmış migration'lar bir izleme tablosunda (Flyway'de flyway_schema_history) kaydedilir, böylece her migration tam bir kez çalışır.

PostgreSQL

-- V2__siparis_tablosu.sql
CREATE TABLE siparis (
  id       bigserial PRIMARY KEY,
  tutar    numeric(12,2) NOT NULL,
  olusma   timestamptz DEFAULT now()
);

2. Checksum ile değişmezliği koru

Flyway/Liquibase her uygulanmış migration'ın checksum'ını (özet) saklar. Zaten uygulanmış bir dosyayı sonradan düzenlersen checksum tutmaz ve araç hata verir. Kural: uygulanmış bir migration'ı ASLA düzenleme; düzeltmeyi yeni bir sürüm dosyasıyla yap. Bu, tüm ortamların (dev/staging/prod) aynı geçmişi paylaşmasını garanti eder.

PostgreSQL

# checksum uyuşmazlığında onarım (dikkatli kullan):
flyway repair
# doğru yol: değişikliği yeni Vx dosyasıyla ekle

3. Mevcut veritabanına baseline uygula

Migration aracını zaten dolu, geçmişsiz bir veritabanına bağlarken baseline kullan; bu mevcut durumu 'başlangıç sürümü' kabul eder ve eski nesneleri yeniden oluşturmaya çalışmaz. baselineVersion'dan sonraki migration'lar uygulanır. Sıfırdan kurulan ortamda baseline gerekmez, migration'lar V1'den itibaren çalışır.

PostgreSQL

flyway baseline -baselineVersion=1 -baselineDescription="mevcut sema"

4. CI pipeline'da otomatik migrate et

CI adımında migration aracını çalıştırıp değişiklikleri test ve staging veritabanına otomatik uygula; migrate komutu yalnızca yeni (uygulanmamış) dosyaları çalıştırır, idempotenttir. Önce migration'ı geçici/ephemeral bir veritabanına uygulayıp doğrulamak, bozuk SQL'i prod'a gitmeden yakalar. Uygulama kodu deploy'undan ÖNCE şema migrate edilmeli (geriye uyumlu değişimlerle).

PostgreSQL

# CI adımı (Flyway)
flyway -url=jdbc:postgresql://staging/uygulama \
  -user=ci -password=$PW migrate

MySQL

flyway -url=jdbc:mysql://staging/uygulama \
  -user=ci -password=$PW migrate

5. Prod'da manuel onay kapısı koy

Test/staging otomatik, ama prod migrate'ini elle onaya bağla; CI/CD içinde bir 'approval gate' (manuel onay) adımı ekle. Onaydan önce 'flyway info' veya 'liquibase status' ile hangi migration'ların çalışacağını göster. Prod'a uygulamadan önce mutlaka güncel bir yedek al; böylece sorun olursa geri dönebilirsin.

PostgreSQL

# onaydan önce ne çalışacak?
flyway info
# liquibase karşılığı:
liquibase status --verbose

6. Geri alınabilirlik ve rollback stratejisi belirle

Flyway Community'de otomatik geri alma yoktur; düz ileri (forward-only) migration ilkesini benimse: bir hatayı geri almak yerine düzelten yeni bir migration yaz. Liquibase changeset'lerinde rollback bloğu tanımlanabilir ve 'liquibase rollback' ile geri alınabilir. En sağlam strateji: değişimleri küçük ve geriye uyumlu tut, riskli işlemlerden (kolon silme) önce yedek al, geri dönüş planını yazılı hazırla.

PostgreSQL

-- Liquibase rollback örneği (changeset içinde)
--changeset dev:2
CREATE TABLE siparis (...);
--rollback DROP TABLE siparis;
DBAtlas'ta aç →