AI Destekli Yazılım Geliştirmede Veritabanı Göçü Güvenlik Hattı

AI destekli yazılım geliştirmede göç çıktısını bir sözleşmeye bağlamak

Generative AI veya bir kod ajanı SQL ürettiğinde asıl risk yalnızca sözdizimi hatası değildir. Model, bir kolonu silip uygulamanın eski sürümündeki sorguları kırabilir, milyonlarca satırlı tabloda tabloyu yeniden yazdırabilir ya da uzun süren ACCESS EXCLUSIVE kilidi yaratabilir. Bu nedenle ajan çıktısını serbest SQL olarak değil, her değişikliği makinece denetlenebilir metadata taşıyan bir göç sözleşmesi olarak kabul edin. Örneğin her dosya için etkilenen tablo, geri alma yaklaşımı, beklenen kilit seviyesi ve expand-contract aşaması zorunlu alanlar olsun.

-- migration: 20260827_add_customer_status.sql
-- contract: expand
-- tables: customers
-- max_lock: SHARE UPDATE EXCLUSIVE
-- rollback: keep_column_until_release_2026_09

ALTER TABLE customers
  ADD COLUMN status text;

ALTER TABLE customers
  ADD CONSTRAINT customers_status_check
  CHECK (status IN ('active', 'inactive')) NOT VALID;

PostgreSQL'de NOT VALID ile eklenen CHECK kısıtı mevcut satırları ilk anda taramaz; yeni yazımları denetlemeye başlar. Sonraki dağıtımda VALIDATE CONSTRAINT çalıştırmak, büyük tabloda uzun süreli tablo kilidi oluşturmadan doğrulama yapabilmenizi sağlar.

Docker ile shadow database ve uygulama sözleşme testleri

Yapay zeka eğitimi veya yapay zeka kursu sırasında SQL üretimini değerlendirmenin en güvenilir yolu, migration'ı boş bir veritabanında çalıştırmak değildir. Production'a benzer şema ve temsil edici veri dağılımı içeren bir shadow database kurun; önce ana dalın şemasını, sonra aday dalın göçlerini uygulayın. Docker eğitiminde öğrenilen volume ve healthcheck ayrıntıları burada doğrudan işe yarar: test başlamadan PostgreSQL hazır kabul edilirse migration runner rastlantısal connection refused hataları üretir.

docker run --rm -d --name shadow-pg   -e POSTGRES_PASSWORD=test   -e POSTGRES_DB=app_shadow   -p 55432:5432   postgres:16

until pg_isready -h localhost -p 55432 -U postgres; do sleep 1; done
psql postgresql://postgres:test@localhost:55432/app_shadow   -f schema/main.sql
psql postgresql://postgres:test@localhost:55432/app_shadow   -f db/migration/20260827_add_customer_status.sql

Buradaki sürüm etiketi örnek bir container imajıdır; ekip, production ile uyumlu major sürümü kendi kilitli bağımlılık manifestinden seçmelidir.

CI CD pipeline içinde şema farkı, veri doğrulama ve geri dönüş kapısı

CI CD pipeline aşamasını üç ayrı kapıya bölün: SQL statik analiz, shadow database migration ve uygulama sözleşme testi. Tek bir integration testi başarısız olduğunda hangi güvence katmanının ihlal edildiği anlaşılmaz. Aşağıdaki GitHub Actions örneğinde migration önce geçici PostgreSQL servisine uygulanıyor, sonra pgTAP koşuyor; production kimlik bilgisi bu job'a hiç verilmez.

jobs:
  schema-contract:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: shadow
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 2s --health-timeout 3s --health-retries 20
    steps:
      - uses: actions/checkout@v4
      - run: pipx run sqlfluff lint db/migration --dialect postgres
      - run: ./gradlew flywayMigrate -Dflyway.url=jdbc:postgresql://localhost:5432/shadow
      - run: pg_prove -h localhost -U postgres test/schema/*.sql

Şema farkını ayrıca Atlas, Liquibase diff veya migra ile raporlayın. Beklenmeyen bir DEFAULT değişikliği ya da indeks silinmesi, test verisinde görünmese bile diff çıktısında inceleme gerektiren bir değişiklik olarak işaretlenmelidir.

Kilit ve sorgu maliyetini ölçerek migration performansını karşılaştırmak

Büyük tabloda yapılan bir migration'ın kabul kriteri 'lokalde hızlı çalıştı' olmamalıdır. Önce production benzeri satır sayısı ve indeks yoğunluğuyla staging ortamında pg_stat_statements, pg_locks ve k6 kullanarak bir baz ölçüm alın. Ardından aynı yük altında aday migration'ı çalıştırın; p95 istek gecikmesi, lock wait süresi, deadlock sayısı ve migration süresini karşılaştırın. PostgreSQL'de pg_stat_activity içindeki wait_event_type değeri Lock ise uygulama gecikmesinin CPU'dan değil, migration'ın tuttuğu kilitten kaynaklandığını doğrudan gösterir.

SELECT pid, wait_event_type, wait_event, state, query
FROM pg_stat_activity
WHERE datname = current_database()
  AND (wait_event_type = 'Lock' OR state <> 'idle');

SELECT mode, granted, relation::regclass
FROM pg_locks
WHERE relation = 'customers'::regclass;

Vibe coding eğitimi için cloud native migration laboratuvarı

Bir vibe coding eğitimi veya vibe coding kursu, modelin SQL yazdırdığı kısa demolarla sınırlı kalmamalı. Ölçülebilir laboratuvar çıktısı olarak bir migration repository, shadow test job'ı, k6 raporu ve geri alma runbook'u isteyin. Bu çalışma aynı zamanda yazılım eğitimi, teknoloji eğitimi, llm eğitimi ve generative ai kullanımında kritik olan insan onay sınırını somutlaştırır: LLM öneri üretir, merge yetkisi ise diff, test ve ölçüm artefaktlarını inceleyen mühendistedir.

Sık Sorulan Sorular

AI destekli yazılım geliştirme ile üretilen SQL migration nasıl test edilir?

Önce Flyway veya Liquibase ile geçici bir PostgreSQL shadow database'e migration'ı uygulayın, sonra pgTAP ile kolon, indeks, constraint ve RLS policy beklentilerini doğrulayın. Son olarak Atlas veya migra ile ana dal ve aday dal şemalarının diff çıktısını code review'a ekleyin.

CI CD pipeline içinde PostgreSQL migration kilidi nasıl ölçülür?

Staging'de pg_stat_activity ile wait_event_type = 'Lock' oturumlarını, pg_locks ile relation ve lock mode bilgisini toplayın. Aynı anda k6 çalıştırıp before.json ve after.json dosyalarındaki http_req_duration p95 değerlerini karşılaştırın. Uzun ACCESS EXCLUSIVE beklemeleri varsa migration'ı expand-contract adımlarına bölün.

Docker eğitimi ve Kubernetes eğitimi için migration laboratuvarı nasıl kurulur?

Docker Compose veya docker run ile healthcheck bekleyen geçici PostgreSQL başlatın, migration ve pgTAP testlerini CI job'ında çalıştırın. Sonra minikube üzerinde migration'ı ayrı bir Kubernetes Job olarak dağıtın; eşzamanlı Job'ları PostgreSQL pg_advisory_lock ile seri hale getirin.

Terraform ile infrastructure as code kullanırken migration rolü neden ayrılmalıdır?

Uygulama runtime rolü DML ile sınırlıyken migrator rolüne kontrollü DDL verilir. Terraform'daki postgresql_grant kaynakları bu ayrımı tekrarlanabilir hale getirir. Böylece uygulama container'ındaki bir credential sızıntısı doğrudan şema silme yetkisine dönüşmez.