Netlify Deploy Previews Nedir? Pull Request İnceleme Rehberi

Netlify Deploy Previews, Git tabanlı bir projede pull veya merge request içindeki değişiklikleri production’dan ayrı bir URL’de build edip gösteren geçici inceleme ortamlarıdır. Tasarımcı, geliştirici, QA, içerik ekibi ve ürün yöneticisi aynı commit’in çalışan sürümünü merge öncesinde görebilir. Ancak Deploy Preview yalnız “geçici link” değildir; doğru yapılandırıldığında UI, form, environment, erişim ve entegrasyon kontrollerini production’a çıkmadan bir araya getiren review katmanıdır.

Preview ortamı production’ın birebir kopyası kabul edilmemelidir. URL, veri kaynağı, secret’lar, erişim politikası, cache ve üçüncü taraf callback’leri farklı olabilir. Bu farklar bilinçli yönetildiğinde Deploy Preview hem hız hem kalite kazandırır; yönetilmediğinde production verisine dokunan public bir test ortamına dönüşebilir.

Öne Çıkanlar

• Deploy Preview genellikle pull request açıldığında veya güncellendiğinde oluşur.
• Her preview belirli bir commit ve deploy ID ile ilişkilidir.
• İnceleyen kişi yerel proje kurmadan çalışan değişikliği görebilir.
• Preview oluşturma production-deploy kredisi tüketmeyebilir; URL trafiği, bandwidth ve dinamik servisler yine kullanım yaratabilir.
• Preview environment variables ve test verisi production’dan ayrılmalıdır.
• Uzun ve tahmin edilmesi zor URL, access control yerine geçmez.
• Merge sonrası production smoke test hâlâ gereklidir.

1. Deploy Preview Nedir ve Ne Zaman Oluşur?

Netlify Deploy Previews, repository bağlantılı projelerde pull request yaşam döngüsüne bağlanır. Geliştirici branch’ini Git sağlayıcısına gönderip pull request açtığında Netlify ilgili commit’i build eder ve ayrı bir deploy oluşturur. PR’a yeni commit geldikçe preview güncellenebilir.

Tipik akış:

``text Feature branch ↓ Pull request ↓ Netlify build ↓ Deploy Preview URL ↓ Review ve test ↓ Merge ↓ Production deploy ``

Preview, production domain’ini değiştirmez. Aynı anda birden fazla PR’ın farklı preview’ları çalışabilir. Bu, iki tasarım veya özellik değişikliğinin birbirini beklemeden incelenmesini sağlar.

Deploy Preview oluşmuyorsa şu alanları kontrol edin:

• Repository ve Git provider bağlantısı aktif mi?
• Pull request doğru base branch’e mi açıldı?
• Deploy Preview ayarı veya build ignore kuralı devre dışı mı?
• Build başarısız mı?
• Git sağlayıcısındaki Netlify check’in yetkisi var mı?
• Proje kredi limiti nedeniyle paused durumda mı?

2. Preview URL’leri Nasıl Çalışır?

Netlify preview URL’leri deploy veya pull request kimliğini proje alt alan adıyla birleştirir. URL biçimi platformun güncel uygulamasına göre değişebilir; yaygın örnek şu şekildedir:

``text https://deploy-preview-42--site-name.netlify.app ``

Bu URL belirli preview context’ini gösterir. Bazı dashboard ve Git sağlayıcı arayüzleri ayrıca deploy’a sabit permalink veya en güncel PR preview bağlantısı sunabilir. Test raporuna hangi URL tipinin kullanıldığını yazın; hareket eden “latest preview” bağlantısı ile sabit deploy bağlantısı aynı amaçta değildir.

URL’nin uzun olması onu private yapmaz. Link PR yorumunda, chat mesajında, analytics logunda veya üçüncü taraf serviste görünebilir. Hassas içerik için team login, password veya planın sunduğu deploy protection seçenekleri kullanılmalıdır.

Preview’ın arama motorları tarafından indekslenmemesi için Netlify çeşitli varsayımlar uygulayabilir; yine de güvenlik veya gizlilik kararını yalnız robots davranışına bırakmayın. noindex erişim engeli değildir.

3. Bir Pull Request Deploy Preview ile Nasıl İncelenir?

İnceleme, “link açıldı” yorumundan daha sistematik olmalıdır. Önce pull request kapsamını okuyun, sonra çalışan sürümde kabul kriterlerini test edin.

Geliştirici kontrolü

• Build logu temiz mi?
• Doğru commit SHA deploy edildi mi?
• Console ve Network hatası var mı?
• Function veya Edge Function logu hata veriyor mu?
• Yeni environment variable preview context’te tanımlı mı?
• Geriye uyumsuz API veya schema değişikliği var mı?

Tasarım kontrolü

• Figma veya kabul edilen tasarımla spacing ve typography uyumlu mu?
• 320–1440 px arası kritik breakpoint’ler nasıl?
• Uzun metin, boş state, loading ve error state görülebiliyor mu?
• Keyboard focus ve renk kontrastı yeterli mi?
• Görseller doğru aspect ratio ve dosya boyutunda mı?

QA kontrolü

• Happy path ve en az bir hata durumu çalışıyor mu?
• Doğrudan iç URL açıldığında route çözülüyor mu?
• Form iki kez gönderildiğinde davranış ne?
• Refresh, back/forward ve yeni sekme akışı doğru mu?
• Mobile browser ve temel desktop browser’larda fark var mı?

İçerik/ürün kontrolü

• Başlık, fiyat, tarih ve hukuki metin doğru mu?
• CTA doğru yere mi gidiyor?
• Analytics event production’a yanlış veri gönderiyor mu?
• Feature flag ve rol koşulu beklenen kullanıcıya mı açılıyor?

Her rol test ettiği alanı PR’da kısa ama somut biçimde kaydetmelidir. “LGTM” yerine “iPhone 13 viewport, Chrome desktop, /checkout hata state ve sandbox ödeme denendi” gibi kayıt daha değerlidir.

4. Ekip Geri Bildirimi ve Approval Akışı Nasıl Kurulur?

Netlify’nin collaborative preview özellikleri, sayfa üzerinde yorum veya Git sağlayıcıya bağlı geri bildirim akışları sunabilir. Özellik kapsamı plan ve güncel ürün arayüzüne göre değişebilir. Araçtan bağımsız olarak review süreci şu kurallara dayanmalıdır:

1. Her PR’da kabul kriterleri yazılı olsun. 2. Preview URL ve commit SHA otomatik eklensin. 3. Tasarım, teknik ve veri sahibi roller net olsun. 4. Blocker ile öneri ayrıştırılsın. 5. Yeni commit geldiğinde eski approval’ın geçerliliği tanımlansın. 6. Merge için zorunlu status check ve review sayısı belirlensin. 7. Production smoke test’in sahibi atansın.

Görsel yorumda ekran boyutu, URL, gözlenen davranış ve beklenen davranış yazılmalıdır. “Burayı düzeltelim” türü yorumlar yeniden üretilebilirlik sağlamaz.

Çok küçük ekipte her PR için üç kişi şart olmayabilir. Risk tabanlı review kullanın: yazım düzeltmesi hafif kontrolden, authentication veya ödeme değişikliği daha kapsamlı testten geçebilir.

5. Environment Variables ve Erişim Farkları

Deploy Preview, production’dan ayrı context’tir. Environment variables da context’e göre ayrılmalıdır.

Alan	Production	Deploy Preview
API	Canlı	Sandbox
Database	Main	Preview branch/test DB
E-posta	Gerçek gönderim	Allowlist veya yakalama servisi
Ödeme	Live	Test mode
Analytics	Production property	Dev property veya kapalı
Feature flags	Canlı kurallar	Test varyantları

Production secret’ını preview’a açmak, özellikle dış katkıcının branch’i build ediliyorsa risk yaratabilir. Build script’i veya dependency lifecycle script’i değerleri okuyabilir. Preview için en düşük yetkili ve kısa ömürlü credential kullanın.

Erişim açısından üç soru sorun:

• Preview URL’sini kim açabilir?
• Netlify dashboard/loglarına kim erişebilir?
• Preview’ın bağlandığı üçüncü taraf servislerde hangi işlem yapılabilir?

Site public olmasa bile dashboard rolü gereğinden geniş olabilir. Tersine, dashboard’a erişimi olmayan müşteri preview linkini inceleyebilmelidir. Reviewer ve member rollerini güncel plan kapsamına göre ayırın.

6. Preview Güvenliği ve Veri İzolasyonu

Deploy Preview’ın temel threat model’i şöyledir:

• PR kodu güvenilmeyen veya henüz incelenmemiş olabilir.
• Preview URL paylaşılabilir.
• Test kullanıcısı gerçek veri girebilir.
• Üçüncü taraf webhook preview’a istek gönderebilir.
• Preview uzun süre aktif kalabilir.
• Production ile aynı storage kullanılırsa test verisi kalıcı olabilir.

Koruma adımları:

1. Production veritabanından ayrı branch/schema kullanın. 2. Gerçek müşteri verisini kopyalamak yerine sentetik veya maskelenmiş veri kullanın. 3. E-posta ve ödeme servislerini test moduna alın. 4. Preview’a giriş gerekiyorsa test hesapları oluşturun. 5. Uygun access control etkinleştirin. 6. Preview retention ve silme politikasını belirleyin. 7. Browser bundle’da public olmaması gereken değerleri arayın. 8. Preview form ve upload alanlarını abuse açısından sınırlayın.

Cache de veri izolasyonunun parçasıdır. Kullanıcıya özel SSR yanıtı yanlışlıkla public CDN cache’e girerse başka kullanıcıya sunulabilir. Preview’da cache header’larını test etmek production güvenliğine katkı sağlar.

7. Örnek Üç Rollü İnceleme Senaryosu

Briefin istediği özgün çalışma için tek PR’a üç kontrollü değişiklik eklenebilir:

• UI: Hero bölümünün responsive düzeni.
• Form: E-posta validasyonu ve hata mesajı.
• Environment-dependent davranış: Preview’da sandbox API etiketi.

Roller:

Rol	Test	Olası bulgu
Tasarımcı	375, 768 ve 1440 px görünüm	Tablet breakpoint’te taşma
QA	Geçerli/geçersiz form, refresh	Hata mesajı focus almıyor
Geliştirici	Env, console, network, log	Preview yanlış API origin kullanıyor

Her yorumun başlangıç ve bitiş zamanı kaydedilebilir. Ancak üç kişilik küçük testten “Deploy Preview review süresini yüzde X azaltır” gibi geniş bir sonuç çıkarılmamalıdır. Test yalnız süreci görünür kılar.

> Editör notu — zorunlu özgün kanıt: Bu taslak hazırlanırken üç değişiklikli gerçek PR ve üç rol incelemesi yapılmadı. Yayından önce aynı commit üzerinde tasarımcı, QA ve geliştirici ayrı checklist kullanmalı; inceleme süresi, yakalanan sorun, ekran boyutu ve commit SHA kaydedilmelidir. Katılımcı yoksa rol simülasyonu açıkça belirtilmelidir.

8. Rollback ve Production’a Geçiş

PR onaylanıp merge edildiğinde production branch değişir ve yeni production deploy başlar. Preview’ın başarılı olması production’ın kesin başarılı olacağı anlamına gelmez; production-only environment variables, custom domain, cookie, cache veya veri kaynağı farkı olabilir.

Merge sonrası smoke test:

• Ana domain doğru deploy ID’yi gösteriyor mu?
• Production API ve database bağlantısı çalışıyor mu?
• Login/cookie custom domain’de doğru mu?
• Form ve ödeme gerçek ama kontrollü testte çalışıyor mu?
• Function/Edge loglarında yeni hata var mı?
• Analytics doğru property’ye gidiyor mu?

Hata durumunda önceki atomik production deploy tekrar yayınlanabilir. Bu rollback yalnız deploy dosyası ve platform kodunu geri alır; database migration, gönderilmiş e-posta veya ödeme işlemini otomatik geri çevirmez.

9. Deploy Preview Ne Zaman Yeterli Değildir?

Deploy Preview güçlüdür fakat şu testlerin tamamının yerine geçmez:

• Gerçek production yük testi,
• Uzun süreli soak test,
• Gerçek DNS ve custom domain cookie testi,
• Production veri migration doğrulaması,
• Formal penetration test,
• Çok bölgeli latency analizi,
• Gerçek kullanıcı araştırması,
• Regülasyon veya erişilebilirlik audit’i.

Preview ortamı kısa ömürlü ve düşük trafikliyse race condition, cache stampede veya vendor quota sorunlarını göstermeyebilir. Kritik sistemlerde staging, canary, feature flag ve observability ile birlikte kullanılmalıdır.

Deploy Preview Kontrol Listesi

• [ ] PR kapsamı ve kabul kriterleri açık.
• [ ] Preview doğru commit SHA’yı gösteriyor.
• [ ] Build warning ve loglar okundu.
• [ ] UI breakpoint ve erişilebilirlik kontrol edildi.
• [ ] Form/API happy path ve hata durumu test edildi.
• [ ] Preview sandbox veri ve servislerini kullanıyor.
• [ ] Production secret’ları gereksiz yere açık değil.
• [ ] Preview erişimi bilinçli yapılandırıldı.
• [ ] Browser console ve Network temiz.
• [ ] Merge sonrası production smoke test sahibi belli.
• [ ] Rollback ve migration etkisi biliniyor.

> Görsel notu: PR → build → preview URL → üç rol geri bildirimi → merge → production akışını gösteren özgün diyagram ile gerçek preview ekranları hazırlanmalıdır. Kişisel veri ve token’lar maskelenmelidir.

> İç link editör notu: Deploy türleri, GitHub deploy ve Agent Runners yazıları yayına girdiğinde ilgili bölümlere doğal bağlantı eklenmelidir.

Sık Sorulan Sorular

Deploy Preview yalnız geliştiriciler için mi?

Hayır. Tasarımcı, QA, içerik, ürün ve müşteri ekipleri çalışan değişikliği kod kurmadan inceleyebilir.

Her pull request otomatik preview oluşturur mu?

Git bağlantısı ve proje ayarları uygunsa genellikle oluşur. Build ignore, permission, başarısız build veya paused project bunu engelleyebilir.

Deploy Preview ücretsiz mi?

Kredi tabanlı planlarda preview oluşturma için production-deploy kredisi alınmayabilir. Preview trafiği, bandwidth, request, Function ve diğer servis kullanımı kredi tüketebilir.

Preview URL private mı?

Yalnız URL’nin uzun olması privacy sağlamaz. Project/deploy visibility ve access control ayarları ayrıca uygulanmalıdır.

Preview onaylanınca production testine gerek var mı?

Evet. Production domain, environment variables, veri kaynağı, cache ve üçüncü taraf entegrasyonları farklı olabilir.

Kaynaklar

• Netlify Deploy Previews
• Deploy Previews documentation
• Compare preview options
• Manage deploys
• Project visibility
• Environment variables

Sonuç

Netlify Deploy Previews, pull request değişikliğini production’dan önce çalışan bir ortamda görünür kılar. Değeri yalnız URL üretmesinden değil; tasarım, QA, içerik, environment ve güvenlik kontrollerini aynı commit üzerinde birleştirmesinden gelir. Preview’ı production kopyası veya gizli ortam kabul etmeyin. Sandbox veri, dar yetkili secret, açık review kriteri ve merge sonrası production smoke test ile kullanın.

Pull request tabanlı Deploy Preview akışını denemek için [ücretsiz Netlify hesabı oluşturabilirsiniz](https://join. netlify. com/wmkqymu1heo2). Bu bir iş ortaklığı bağlantısıdır; bağlantı üzerinden kayıt olmanız veya ücretli plana geçmeniz halinde Ortak Alan komisyon kazanabilir.