Deploy Preview, Branch Deploy ve Production Deploy Arasındaki Farklar

Netlify deploy türleri aynı kodu farklı amaçlarla yayınlar. Production Deploy, canlı domain’in kullandığı sürümdür. Deploy Preview, pull veya merge request içindeki değişikliği geçici bir review URL’sinde gösterir. Branch Deploy ise seçilen Git branch’inin daha uzun ömürlü, branch’e bağlı ortamını oluşturur. Üçü de çalışan site üretebilir; tetikleyici, URL, environment variables, yaşam döngüsü, erişim ve kredi etkileri aynı değildir.

Doğru ayrım yapılmadığında staging anahtarının production’da kullanılması, public preview’da gerçek veri görünmesi veya her küçük değişiklikte gereksiz production deploy oluşturulması gibi sorunlar ortaya çıkar. En sağlıklı yöntem, aynı commit’i üç context’te karşılaştıran açık bir ortam matrisi kurmaktır.

Öne Çıkanlar

• Production Deploy, production branch üzerinden ana domain’i günceller.
• Deploy Preview, pull/merge request’e bağlıdır ve review için tasarlanır.
• Branch Deploy, belirli non-production branch’i sürekli bir URL’de tutar.
• Her context farklı environment variable ve erişim politikası kullanabilir.
• Kredi tabanlı planda başarılı production deploy 15 kredi tüketirken preview ve branch deploy oluşturma için bu kalem alınmaz.
• Preview ve branch URL’lerine gelen trafik web request, bandwidth ve compute tüketebilir.
• Rollback production kodunu geri alabilir; veri migration’ını otomatik geri almaz.

1. Netlify’da Deploy Context Ne Anlama Gelir?

Deploy context, build’in hangi amaçla çalıştığını ve hangi yapılandırmayı kullanacağını belirten ortam bilgisidir. Netlify’de temel context’ler şunlardır:

• production: Canlı branch ve ana domain,
• deploy-preview: Pull/merge request preview’ları,
• branch-deploy: Production olmayan belirli branch deploy’ları,
• Belirli branch adları: Örneğin staging için özel override.

Context, yalnız URL etiketi değildir. Build command, environment variables, redirects, access control ve dış servis hedefleri context’e göre değişebilir.

netlify. toml örneği:

```toml [build] command = "npm run build" publish = "dist"

[context. deploy-preview] command = "npm run build:preview"

[context. branch-deploy] command = "npm run build:staging"

[context. staging. environment] APP_ENV = "staging" ```

Gerçek secret değerlerini repository’deki TOML dosyasına yazmayın. Dashboard veya güvenli secret yönetimi kullanın.

2. Production Deploy Nasıl Tetiklenir ve Hangi URL’yi Kullanır?

Production Deploy, genellikle main veya proje ayarlarında seçilen production branch’e gelen commit ile tetiklenir. Manuel publish veya CLI/API akışı da production deploy oluşturabilir.

Production URL’leri:

• Projenin ana netlify.app adresi,
• Bağlı custom domain,
• Belirli deploy’a ait immutable permalink.

Kullanıcıların gördüğü ana domain, en son yayınlanan başarılı production deploy’a işaret eder. Yeni build tamamlanmadan mevcut sürüm parça parça değiştirilmez; atomik deploy mantığı eski sürüm ile yeni asset’lerin karışmasını azaltır.

Production context’te genellikle şunlar bulunur:

• Canlı API ve database,
• Gerçek analytics property,
• Live ödeme modu,
• Production e-posta gönderimi,
• Custom domain cookie ayarları,
• Arama motoru indeksleme politikası.

Kredi tabanlı hesaplarda başarılı production deploy başına 15 kredi tüketimi vardır. Başarısız build veya rollback’in aynı kalemdeki güncel davranışı resmî billing dokümanından doğrulanmalıdır.

3. Deploy Preview Nasıl Oluşur?

Deploy Preview, Git provider’da pull veya merge request açıldığında oluşur. PR’a yeni commit eklendiğinde yeni preview deploy üretilebilir. Amaç, değişikliği production’a merge etmeden çalışan ortamda incelemektir.

Yaygın URL biçimi:

``text deploy-preview-42--site-name.netlify.app ``

Preview context için önerilen yapı:

• Sandbox API,
• Preview database branch veya test schema,
• Test ödeme modu,
• E-posta allowlist’i,
• Development analytics veya analytics kapalı,
• Team login/password gibi uygun erişim politikası.

Deploy Preview geçici review için uygundur; uzun ömürlü staging adresi olarak kullanılmamalıdır. PR kapandığında preview’ın lifecycle ve retention davranışı plan/proje ayarına göre ele alınmalıdır.

Preview oluşturmak production-deploy başına 15 kredi kalemini tüketmez. Ancak preview sayfasının istekleri, asset çıkışı, Function ve AI çağrıları diğer kredi metriklerine girebilir.

4. Branch Deploy Ne Zaman Kullanılmalıdır?

Branch Deploy, seçilen non-production branch için kalıcı veya uzun ömürlü bir URL sağlar. Örneğin staging, develop, campaign-spring veya müşteri demo branch’i kullanılabilir.

Yaygın URL biçimi:

``text staging--site-name.netlify.app ``

Branch’e yeni commit geldikçe aynı branch URL’si en güncel deploy’u gösterebilir. Bu özellik şu senaryolarda faydalıdır:

• Sürekli staging ortamı,
• Birden fazla sprint boyunca yaşayan özellik branch’i,
• İç ekip demo ortamı,
• Bölgesel veya marka varyantı,
• Production’dan önce entegrasyon testi.

Her branch için otomatik deploy açmak gerekmez. Çok sayıda eski branch, aktif URL ve yanlış environment kullanımı yönetim yükü yaratabilir. Hangi branch’lerin deploy edileceğini allowlist ile sınırlamak daha kontrollüdür.

Branch deploy oluşturma production-deploy kredisi tüketmez; ancak aktif branch URL’sine gelen traffic ve dinamik kullanım kredi oluşturabilir.

5. URL, Environment Variables ve Erişim Karşılaştırması

Kriter	Production Deploy	Deploy Preview	Branch Deploy
Ana tetikleyici	Production branch commit/publish	Pull veya merge request	Seçilen non-production branch commit’i
Temel amaç	Canlı kullanıcı trafiği	Değişiklik review’u	Sürekli staging/demo
URL	Ana domain + deploy permalink	PR kimlikli preview URL	Branch adını içeren URL
Yaşam döngüsü	Yeni production sürümüne kadar aktif	PR/deploy yaşam döngüsüne bağlı	Branch var oldukça uzun ömürlü olabilir
Veri kaynağı	Production	Geçici/sandbox	Staging/test
Erişim	Genellikle public	Role/password/team policy	Genellikle kısıtlı staging
İndeksleme	SEO’ya açık olabilir	İndekslenmemeli	İndekslenmemeli
Production deploy kredisi	15 kredi/başarılı deploy	0	0

URL biçimleri ve erişim seçenekleri platform güncellemeleri veya plan kapsamıyla değişebilir. Proje ekranındaki gerçek URL ve visibility ayarını yayın günü doğrulayın.

Environment variable önceliği

Genel team veya project değişkeni context ve branch override’larıyla özelleştirilebilir. Örneğin:

``text API_ORIGIN production → https://api.example.com deploy-preview → https://preview-api.example.com staging branch → https://staging-api.example.com ``

En tehlikeli hata, preview veya branch deploy’un production değerine sessizce fallback etmesidir. Uygulama arayüzünde non-production ortam etiketini gösterin ve API response’tan beklenen environment kimliğini doğrulayın.

6. Kredi ve Kaynak Tüketimi Nasıl Değerlendirilir?

23 Ağustos 2026 itibarıyla kredi tabanlı Netlify fiyatlandırmasında:

• Başarılı production deploy: 15 kredi,
• Deploy Preview ve Branch Deploy: production-deploy kaleminde 0 kredi,
• Bandwidth: GB başına kredi,
• Web request: istek sayısına göre kredi,
• Compute: GB-saat üzerinden kredi,
• AI inference: model sağlayıcısı maliyetine göre kredi.

Bunun sonucu şudur: 100 preview oluşturmak production deploy kaleminde ücret yaratmayabilir; ancak bu preview’lar otomatik botlar tarafından taranır, büyük asset sunar veya Function çalıştırırsa ortak kredi bakiyesini tüketebilir.

Kredi optimizasyonu için:

1. Her branch’i otomatik deploy etmeyin. 2. Gereksiz production commit’lerini PR’da birleştirin. 3. Preview bot ve access politikasını belirleyin. 4. Büyük demo dosyalarını optimize edin. 5. Preview AI/API çağrılarına limit koyun. 6. Usage dashboard’da context bazlı anomali arayın.

Kredi tasarrufu için kalite veya acil güvenlik release’i geciktirilmemelidir. Amaç israfı azaltmak, production akışını yavaşlatmak değildir.

7. Aynı Commit Üç Context’te Nasıl Test Edilir?

Briefin istediği özgün karşılaştırma için tek commit SHA şu sırayla çalıştırılabilir:

1. Pull request açıp Deploy Preview oluşturun. 2. Aynı commit’i staging branch’ine taşıyıp Branch Deploy oluşturun. 3. Onay sonrası production branch’e merge edip Production Deploy oluşturun.

Uygulamada context’i güvenli biçimde gösterin:

``js const context = import.meta.env.PUBLIC_DEPLOY_CONTEXT ?? "unknown"; ``

Client’a yalnız public environment etiketi çıkarılmalıdır; secret gösterilmemelidir.

Test tablosu:

Ölçüm	Preview	Branch	Production
Commit SHA	Kaydedilecek	Aynı	Aynı
URL	Kaydedilecek	Kaydedilecek	Kaydedilecek
Public env etiketi	preview	staging	production
API origin	Sandbox	Staging	Canlı
Deploy süresi	Ölçülecek	Ölçülecek	Ölçülecek
Production deploy kredisi	0	0	15
Visibility	Test edilecek	Test edilecek	Test edilecek
Retention/lifecycle	Kaydedilecek	Kaydedilecek	Kaydedilecek

Deploy süreleri cache durumu, queue ve build image’e bağlıdır. Birer ölçümle genelleme yapılmamalıdır.

> Editör notu — zorunlu özgün kanıt: Bu taslakta aynı commit üç context’te çalıştırılmadı. Yayından önce commit SHA, Netlify planı, build cache durumu, kullanılan runtime, URL, env etiketi, süre ve usage dashboard sonucu kaydedilmelidir. Kredi değerleri billing dokümanından tekrar kontrol edilmelidir.

8. Örnek Ekip Workflow’ları

Küçük ürün ekibi

• Her feature branch için Deploy Preview,
• main merge sonrası production,
• Uzun ömürlü staging branch yok,
• Preview’da sandbox servisler.

Bu model basittir; birden çok özelliğin birlikte entegrasyon testi gerekiyorsa staging eksik kalabilir.

Ajans veya müşteri onay akışı

• PR preview teknik review için,
• client-review branch deploy müşteri sunumu için,
• Onay sonrası production,
• Client review password/team erişimi ile korunur.

Müşteri yorumlarının hangi commit’e ait olduğu kaydedilmelidir; branch URL’si güncellendiğinde eski ekranla yeni kod karışabilir.

Büyük ekip

• Her PR için preview,
• develop veya release branch deploy entegrasyon testi için,
• Feature flag/canary ile production,
• Zorunlu status checks ve role-based approval,
• Audit ve observability.

Burada branch deploy production’a yakın olabilir; yine de production data veya live ödeme varsayılan olmamalıdır.

9. Doğru Deploy Türü İçin Karar Tablosu

Sorunuz	Kullanılacak deploy
Tek PR değişikliğini merge öncesi görmek istiyorum	Deploy Preview
Her gün güncellenen sabit staging URL’si istiyorum	Branch Deploy
Kullanıcıların göreceği canlı sürümü yayınlıyorum	Production Deploy
Müşteri iki hafta aynı demo URL’sini kullanacak	Branch Deploy
Tasarımcı tek component değişikliğini inceleyecek	Deploy Preview
Hatalı canlı sürümden önceki koda dönüyorum	Eski Production Deploy’u rollback/re-publish

Netlify Deploy Türlerinde Yaygın Hatalar

Preview production API’ye bağlanıyor

Context override eksik veya değişken adı yanlış olabilir. Uygulamada environment etiketi ve API health response kontrolü ekleyin.

Branch deploy search sonuçlarında çıkıyor

Access control, canonical ve noindex politikası eksik olabilir. noindex tek başına gizlilik sağlamaz; staging’i gerektiğinde erişimle koruyun.

Production URL eski commit’i gösteriyor

Yeni deploy build edilmiş ama publish edilmemiş, farklı production branch seçilmiş veya eski immutable URL açılmış olabilir. Deploy ID ve ana domain ilişkisini kontrol edin.

Aynı commit farklı sonuç veriyor

Environment variable, cache, build image, dependency resolution veya context-specific command farklı olabilir. Lockfile ve context yapılandırmasını karşılaştırın.

Rollback sonrası uygulama bozuk

Kod eski sürüme dönmüş, database schema ileri sürümde kalmış olabilir. Backward-compatible migration ve rollback planı gerekir.

Güvenlik ve Retention Kontrol Listesi

• [ ] Preview ve branch deploy production data kullanmıyor.
• [ ] Her context’in görünürlüğü ayrı test edildi.
• [ ] Non-production URL’ler indekslenmiyor ve gerekiyorsa korunuyor.
• [ ] Secret scope yalnız gerekli context’e açık.
• [ ] Eski branch deploy’ların sahibi ve silme politikası var.
• [ ] Production merge sonrası smoke test yapılıyor.
• [ ] Rollback ile database etkisi ayrı değerlendiriliyor.
• [ ] Usage dashboard’da preview/branch trafiği izleniyor.

> Görsel notu: Aynı commit’in Preview, Branch ve Production URL’lerini; env etiketlerini ve tetikleyicilerini üç sütunda gösteren özgün context matrisi hazırlanmalıdır.

> İç link editör notu: Deploy Previews, Netlify CLI ve fiyatlandırma yazıları yayına girdiğinde ilgili bölümlere doğal bağlantı eklenmelidir.

Sık Sorulan Sorular

Deploy Preview ile Branch Deploy aynı mı?

Hayır. Preview pull request’e ve review yaşam döngüsüne; Branch Deploy belirli Git branch’ine bağlı uzun ömürlü ortama yöneliktir.

Branch Deploy production’a dönüşür mü?

Aynı branch production branch olarak seçilmedikçe ana domain’i otomatik olarak production yapmaz. Kod production branch’e merge edilip production deploy oluşturulur.

Preview ve branch deploy kredi tüketmez mi?

Production-deploy oluşturma kaleminde 15 kredi tüketmezler. Trafik, bandwidth, Function, Database veya AI kullanımı ortak kredi havuzunu etkileyebilir.

Her context için ayrı environment variable olabilir mi?

Evet. Deploy Preview, branch ve production context’leri için farklı değer ve scope tanımlanabilir.

Production rollback preview’ı etkiler mi?

Production’a eski deploy’u yeniden yayınlamak preview/branch deploy’larını aynı biçimde geri almaz. Her deploy kendi sürüm kaydına sahiptir.

Kaynaklar

• Production Deploys
• Deploy Previews
• Branch Deploys
• Compare preview options
• How credits work
• File-based configuration

Sonuç

Netlify deploy türleri arasındaki temel fark, aynı kodun hangi amaç ve risk düzeyiyle yayınlandığıdır. Deploy Preview tek değişikliği incelemek, Branch Deploy sürekli staging veya demo ortamı sağlamak, Production Deploy ise canlı kullanıcı trafiğini taşımak için kullanılır. URL, environment variables, erişim, veri kaynağı ve kredi etkisini ayrı tasarlayın. Aynı commit’i üç context’te test etmek, ortam farklarını doküman okumaktan daha görünür hâle getirir.

Preview, branch ve production context’lerini aynı projede karşılaştırmak için [ücretsiz hesap 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.