Vercel ile Dağıtım ve Önizleme Ortamları

Modern web geliştirme süreçlerinde dağıtım (deployment) artık sadece "sunucuya dosya atmak" değil. Ekipler büyüdükçe, feature branch'ler çoğaldıkça ve müşteri geri bildirimleri hızlandıkça, ortam yönetimi kritik bir mühendislik meselesi hâline geliyor. Vercel tam da bu noktada işleri inanılmaz derecede kolaylaştıran bir platform. Birkaç aydır aktif olarak kullandığım deneyimlerimden yola çıkarak önemli gördüğüm başlıkları paylaşmak istedim.

Üç Temel Ortam: Development, Preview, Production

Vercel'in çalışma mantığı üç katmana dayanıyor:

• Development: Kendi makinenizde vercel dev komutuyla yerel ortamı Vercel'in edge fonksiyonlarına yakın biçimde çalıştırırsınız. Ortam değişkenleri bile production'dakiyle birebir eşleşebilir.
• Preview: Her pull request açıldığında Vercel otomatik olarak benzersiz bir URL üretir ve uygulamayı oraya dağıtır. Bu sayede "bende çalışıyor" tartışmaları tarihe karışır.
• Production: main (ya da belirlediğiniz) branch'e merge yapıldığında otomatik olarak tetiklenen nihai dağıtım ortamı.

Bu üçlü yapı sayesinde ekip içi inceleme, müşteri onayı ve canlıya alma adımlarının her biri izole ve tekrarlanabilir oluyor.

Preview URL'leri Gerçekten Hayat Kurtarıyor

Daha önce bir projeyi "staging ortamına al, linki paylaş, geri bildirim bekle" döngüsüyle yönetmeye çalışmış biri olarak şunu net söyleyebilirim: Preview URL'leri bu döngüyü neredeyse ortadan kaldırıyor.

Her PR için otomatik üretilen URL'nin birkaç güçlü özelliği var:

• Kalıcı ve paylaşılabilir: PR kapanana kadar erişilebilir durumda kalır.
• Ortam değişkeni desteği: Preview ortamına özel değişkenler tanımlayabilirsiniz (test API anahtarları, mock servisler vb.).
• Yorum entegrasyonu: GitHub/GitLab üzerinde PR yorumlarına doğrudan preview linki düşer; ürün yöneticisi ya da tasarımcı tek tıkla değişikliği görebilir.

Ortam Değişkenlerini Doğru Yönetmek

Vercel Dashboard üzerinden ortam değişkenlerini üç kapsama atayabilirsiniz:

1. Production – Yalnızca canlı ortamda geçerli. 2. Preview – Tüm PR dağıtımlarında geçerli. 3. Development – vercel env pull komutuyla yerel .env.local dosyanıza çekilir.

Bu yapı sayesinde DATABASE_URL gibi hassas değişkenler production dışına sızmadan, test ortamlarında güvenli alternatiflerle çalışabiliyorsunuz. Ayrıca belirli bir branch için farklı bir değişken tanımlamak da mümkün; örneğin staging branch'ine ayrı bir API endpoint atayabilirsiniz.

CI/CD ile Entegrasyon

Vercel'in en sık gözden kaçan özelliklerinden biri, dağıtım sürecine müdahale etmeyi sağlayan Deployment Protection ve Vercel CLI komutları. Özellikle kurumsal projelerde:

• vercel --prod komutuyla manuel production dağıtımı tetiklenebilir.
• GitHub Actions içinden vercel deploy --prebuilt ile build adımı CI'dan, dağıtım adımı Vercel'den yapılabilir; bu hem maliyet hem hız açısından avantajlı.
• Deploy Hooks aracılığıyla harici bir CMS güncellemesi ya da zamanlanmış bir görev, yeniden dağıtım başlatabilir.

Dikkat Edilmesi Gereken Noktalar

Her şey pembe değil elbette. Birkaç uyarı:

• Ücretsiz plandaki bant genişliği limitleri preview ortamları dahil tüm dağıtımlara uygulanır; trafik yoğun projelerde fatura sürpriz yapabilir.
• Monorepo kullanıyorsanız vercel.json içindeki buildCommand ve outputDirectory ayarlarını özenle yapılandırmak gerekiyor, aksi hâlde yanlış proje dağıtılabilir.
• Preview URL'leri herkese açık olduğu için hassas içerikler için Password Protection özelliğini (Pro plan) aktif etmeyi unutmayın.

Sonuç

Vercel'in ortam yönetimi yaklaşımı, özellikle frontend ağırlıklı ve hızlı iterasyon gerektiren projelerde ciddi bir verimlilik artışı sağlıyor. Development'tan production'a uzanan bu katmanlı yapı, hem tek başına çalışan geliştiriciler hem de büyük ekipler için ölçeklenebilir bir temel sunuyor. Denemediyseniz, bir sonraki PR'ınızda preview URL'sine bir göz atmanızı kesinlikle öneririm.