Skip to content
projelere açık000%
Tüm yazılar
ENTRY-013Yayın ve operasyon7 Ağustos 2026 · 3 dk okuma

SER-02 · SER-02.01 · Prototipten Production'a

AI ile geliştirilmiş bir projeyi production'a almadan önce kontrol ettiğim 25 şey

AI ile kod üretimi hızlandıkça production doğrulamasının önemi arttı. Çünkü bir proje çok hızlı biçimde 'çalışıyor' görünür hale gelebiliyor; ama güvenli, ölçülebilir ve geri alınabilir hale gelmesi ayrı bir iştir.

Bir AI coding agent birkaç saat içinde etkileyici miktarda kod üretebilir. Route'lar açılır, auth görünür, dashboard dolu görünür, build alınır. Tam bu noktada yanlış bir güven hissi oluşabiliyor: ürün hazır gibi görünür. Ben production'a çıkmadan önce 'çalışıyor mu?' sorusundan daha geniş bir kontrol yapıyorum.

Production readiness, happy path'in çalışması değil; sistemin kötü koşullarda ne yapacağının bilinmesidir.

A. Kaynak doğrusu ve kod sağlığı

1. Doğru repo, doğru branch, doğru commit

Önce hangi kodun yayınlandığını bilmek gerekir. Local klasör, preview ve production arasında belirsizlik varsa diğer kontrollerin anlamı azalır.

bash
git remote -vgit branch --show-currentgit statusgit log -1 --oneline

2. Çalışma ağacı temiz mi?

Deploy edilecek davranış commit'te olmayan local değişikliklere bağlı olmamalı.

3. Typecheck, lint ve production build geçiyor mu?

Development server toleranslı olabilir. Production bundle gerçek dependency, import ve environment problemlerini daha iyi görünür kılar.

4. Kullanılmayan veya şüpheli dependency var mı?

AI agent'lar küçük bir iş için yeni paket eklemeye eğilimli olabilir. Kullanılmayan dependency hem attack surface hem bakım maliyetidir.

B. Secret, auth ve authorization

5. Secret client bundle'a sızıyor mu?

Service role, ödeme webhook secret'ı, özel API token'ı veya admin credential public environment variable olmamalı.

6. Session persistence gerçek senaryolarda test edildi mi?

Refresh, expired token, offline açılış, yeni sekme ve geri dönüş senaryolarını test ediyorum.

7. Logout gerçekten logout mu?

UI state'i temizlemek ile server session'ını sonlandırmak aynı şey değil.

8. Yetki backend'de uygulanıyor mu?

Buton gizlemek authorization değildir. RLS, server guard veya policy kullanıcı erişimini gerçek veri katmanında sınırlamalı.

C. Veri ve mutation güvenilirliği

9. Veri sahipliği açık mı?

Her kayıt için kullanıcı/organizasyon sahipliği ve erişim modeli açık olmalı.

10. Unique constraint ve foreign key'ler gerçekten var mı?

UI duplicate üretmiyor diye database duplicate'e izin vermemeli.

11. Kritik mutation'lar idempotent mi?

Retry aynı ödeme, ödül veya state değişikliğini iki kez uygulayabiliyorsa production bug'ı kaçınılmaz hale gelir.

ts
type Mutation = {  idempotencyKey: string;  expectedVersion?: number;  payload: unknown;};

12. Delete davranışı tanımlı mı?

Hard delete, soft delete, cascade ve restore kararları sonradan tesadüfen oluşmamalı.

D. Network, cache ve maliyet

13. Aynı veri gereksiz tekrar çekiliyor mu?

Component bazlı fetch çoğalması özellikle dashboard'larda request sayısını sessizce büyütebilir.

14. Polling görünmeyen sekmede devam ediyor mu?

Kullanıcının bakmadığı ekranın backend'i dövmemesi gerekir.

15. Cache policy tanımlı mı?

ts
type CachePolicy = {  staleAfter: number;  refreshOnFocus: boolean;  invalidateOn: string[];};

16. Timeout ve retry kontrollü mü?

Sonsuz retry kullanıcı deneyimini ve backend maliyetini aynı anda bozabilir.

E. Kullanıcı deneyiminin kötü günleri

17. Loading state ilk yükleme ve refresh'i ayırıyor mu?

18. Empty state gerçekten boşluğu açıklıyor mu?

19. Hata durumunda kullanıcı ne yapacağını biliyor mu?

20. Mobil klavye, safe area ve scroll gerçek cihazda test edildi mi?

Özellikle modal, form ve sticky kontroller desktop responsive preview ile doğrulanmış sayılmamalı.

F. Web yüzeyi ve keşfedilebilirlik

21. 404 ve route fallback doğru mu?

22. Canonical, title, description ve OG metadata var mı?

23. Sitemap ve robots gerçek public route'ları yansıtıyor mu?

Authenticated SaaS bile olsa landing, docs, pricing ve public content arama ve paylaşım yüzeyinin parçasıdır.

G. Operasyon

24. Hataları görebilecek miyim?

Console.log monitoring değildir. En azından production error, kritik network failure ve release sürümü izlenebilir olmalı.

25. Geri dönebilecek miyim?

Son kontrol bu. Yeni deploy kırılırsa önceki commit'e dönebiliyor muyum? Migration bunu engelliyor mu? Service worker eski bundle tutuyor mu? Rollback planı varsa release bir kumar olmaktan çıkar.

25 maddeyi tek bir gate'e indirgersem

ts
const productionReady =  codeVerified &&  authVerified &&  dataVerified &&  networkMeasured &&  failureStatesDesigned &&  metadataComplete &&  monitoringVisible &&  rollbackPossible;

Her proje aynı derinlikte kontrol istemez. Ama AI ile geliştirilen projelerde hız arttıkça doğrulama disiplinini azaltmak yerine artırmak gerektiğini düşünüyorum.

  • Production
  • AI Coding
  • Checklist
  • Security
  • Performance
  • Release

SER-02 · SER-02.01

Prototipten Production'a

Çalışan bir MVP'yi güvenilir ürüne dönüştürmek: production kontrolü, modüler refactor, veri migration'ı, audit, rewrite kararı ve release gate'leri.

PROJELERE AÇIK · ÜRÜN VE SİSTEM MİMARI · DEVRALMA / STABİLİZASYON / OPERASYON · WEB · ANDROID · WINDOWS · AHMET CANAL

İletişim

Ürününüz sisteminden hızlı mı büyüdü?

Mevcut durumu, en büyük tıkanmayı ve istediğiniz sonucu yazın. Kapsamı birlikte netleştirelim.

Durum

Yeni danışmanlık ve proje işlerine açık.