Production’a Çıkmakla Ürünün Sahibi Olmak Aynı Şey Değil

“Production’a çıktı.”

Bu cümle çoğu projede final gibi kullanılıyor.

Aslında yalnız bir geçiş.

Kod repository’den çıktı ve kullanıcının karşısına geldi.

Ürün sahipliği ise bundan sonra başlıyor.

Deploy ile ownership arasındaki fark

Deploy sorusu:

“Yeni sürüm yayınlandı mı?”

Ownership soruları:

• Doğru sürüm mü yayınlandı?
• Kritik akışlar canlıda çalışıyor mu?
• Kullanıcı verisi güvende mi?
• Platformlar aynı domain davranışını taşıyor mu?
• Hata olduğunda nereden anlayacağız?
• Bir regression çıkarsa neyi geri alacağız?
• Cache veya stale artifact problemi var mı?
• Bir sonraki release mevcut state’i bozacak mı?

Yeşil CI bu soruların hepsine cevap vermez.

Release bir pipeline değil, acceptance zinciri

Ben production değişikliğini şu zincirle düşünmeyi tercih ediyorum:

Preflight → Root cause → Implement → Build → Render → Interaction → Responsive → Accessibility → Deploy → Live verify

Buradaki kritik nokta şu: sonraki gate öncekinin yerine geçmez.

Build başarılı diye interaction doğru değildir. Deploy başarılı diye live URL güncel değildir. Desktop doğru diye 390px doğru değildir.

Her gate farklı bir riski kapatır.

Canlı URL en son gerçektir

Repository önemli. CI önemli. Hosting dashboard önemli.

Ama kullanıcı bunların hiçbirini görmüyor.

Kullanıcının gördüğü production URL.

Bu yüzden bir değişiklikten sonra son kanıt canlı yüzeydir.

Örneğin Cloudflare “success” gösterebilir ama custom domain eski deployment’a bağlı olabilir. Service worker stale asset verebilir. Production branch ile beklenen branch farklı olabilir.

Bu durumda süreç teknik olarak deploy olmuş ama ürün değişmemiştir.

Ownership bunu fark etmeyi gerektirir.

Multi-platform ownership daha zor

Ordovia gibi web, Android ve Windows yüzeyleri olan bir üründe release yalnız web deploy değildir.

Shared domain davranışı platformlar arasında aynı kalmalı. Native back behavior doğru çalışmalı. Auth/session lifecycle farklı ortamda bozulmamalı. Notification, deep link ve entitlement platforma göre test edilmeli.

Shared codebase leverage sağlar.

Ama ownership, platform farklarını bilerek sınırlandırmadıkça shared codebase yeni regression yolları da açar.

Data ownership release’den bağımsız değildir

Release sırasında sadece UI değişmez.

Schema. RLS. RPC. Cache formatı. Migration. Local durable storage. Feature flags.

Bunların biri değiştiğinde eski client’larla yeni backend’in birlikte yaşayacağı pencere düşünülmeli.

“Yeni version store’a gitti” demek bütün kullanıcıların aynı anda güncellendiği anlamına gelmez.

Bu nedenle production ownership backward compatibility ve rollout riskini de kapsar.

OPERATE neden bakım değildir?

Bakım kelimesi çoğu zaman “bug çıkarsa düzeltiriz” anlamında kullanılıyor.

Ben OPERATE’i daha aktif görüyorum:

• release discipline,
• monitoring,
• dependency/infra risk,
• security/data ownership,
• performance regression,
• integrations,
• platform parity,
• operational decision log.

Amaç ürünü dondurmak değil.

Değişmeye devam ederken kontrolü korumak.

Sonuç

Production’a çıkmak önemlidir.

Ama production bir bitiş çizgisi değil, ürünün artık gerçek koşullarda sorumluluk üretmeye başladığı noktadır.

Kodun canlıya gitmesi delivery’dir.

Canlı ürünün ne taşıdığını bilmek ownership’tir.