Bir uygulama yazdınız, kendi bilgisayarınızda çalışıyor, peki başkaları ona nasıl ulaşacak? İşte deploy tam olarak bu sorunun cevabıdır. Kodunuzu kendi makinenizden alıp internetteki bir sunucuda, gerçek kullanıcıların erişebileceği şekilde çalıştırma sürecinin adıdır.
Bu rehber deploy kavramını sıfırdan açıklar: ne anlama geldiğini, hangi aşamalardan geçtiğini, git push ile bir uygulamanın nasıl canlıya alındığını ve geleneksel yöntemle modern yaklaşımın nerede ayrıştığını adım adım gösterir.
Kısa cevap: deploy (dağıtım), yazdığınız kodu geliştirme ortamından çıkarıp gerçek kullanıcıların erişebileceği canlı bir sunucuya taşıma işlemidir. Süreç üç aşamadan oluşur: kodun çalışabilir bir pakete dönüştürüldüğü build, bu paketin yapılandırmayla birleştiği release ve uygulamanın çalışmaya başladığı run. Modern platformlarda bunların hepsi tek bir git push ile otomatik tetiklenir.
Deploy Nedir?
Deploy, Türkçedeki karşılığıyla dağıtım ya da yayına alma, yazdığınız kodu geliştirme ortamından üretim ortamına taşıyıp çalışır hale getirme işlemidir. Bir başka deyişle, yalnızca sizin bilgisayarınızda çalışan bir uygulamayı, internete bağlı herkesin kullanabileceği bir hizmete dönüştürme adımıdır.
Kavramı somutlaştırmak için basit bir örnek düşünün. Bir web sitesi yazdınız ve tarayıcıda localhost:3000 adresinden açıyorsunuz. Bu adres yalnızca sizin makinenizde geçerlidir; internetteki hiç kimse ona ulaşamaz. Deploy, bu uygulamayı sürekli açık kalan bir sunucuya taşır, ona siteadi.com gibi kalıcı bir adres verir ve dünyanın her yerinden erişilebilir kılar.
Deploy tek bir işlem gibi görünse de aslında birkaç ayrı adımı kapsar: kaynak kodun çalıştırılabilir hale getirilmesi, gerekli ayarların yüklenmesi, uygulamanın başlatılması ve gelen isteklere cevap vermeye hazır olması. Bu adımların tamamına birlikte deployment (dağıtım) denir. "Deploy etmek" ise fiil olarak bu sürecin bir kez çalıştırılması anlamına gelir; her yeni sürüm için tekrar deploy edersiniz.
Önemli bir ayrım: deploy, kodu yazmakla veya test etmekle aynı şey değildir. Kod yazma ve test kendi bilgisayarınızda olur; deploy ise o kodu dış dünyaya açan köprüdür. Bir uygulamanın "canlı" (production) olması, başarılı bir deploy'un tamamlanmış olması demektir.
Deploy'un Üç Aşaması: Build, Release ve Run
Her deploy, arka planda üç mantıksal aşamadan geçer. Bu ayrım keyfi değildir; modern uygulama mimarisinin fiili standardı olan Twelve-Factor App metodolojisi bu üç aşamayı kesin çizgilerle birbirinden ayırır. Aradaki farkı anlamak, bir deploy'un neden başarısız olduğunu teşhis ederken en çok işe yarayan bilgidir.
| Aşama | Ne yapar | Girdi | Çıktı |
|---|---|---|---|
| Build (derleme) | Kaynak kodu çalıştırılabilir bir pakete dönüştürür | Kaynak kod + bağımlılıklar | Değişmez bir yapı (artifact / image) |
| Release (sürüm) | Yapıyı ortam ayarlarıyla birleştirir | Build çıktısı + yapılandırma | Numaralandırılmış, çalışmaya hazır sürüm |
| Run (çalışma) | Sürümü sunucuda başlatır | Release | Canlı, istek karşılayan uygulama |
Build aşamasında kaynak kodunuz alınır, bağımlılıkları (kütüphaneler, paketler) indirilir ve her şey tek bir çalıştırılabilir pakete dönüştürülür. Node.js'te npm install ve derleme adımı, Go'da go build, bir container senaryosunda ise bir image üretimi bu aşamada gerçekleşir. Build'in çıktısı değişmezdir: bir kez üretildikten sonra içeriği değişmeyen bir yapı elde edersiniz. Aynı kaynaktan her zaman aynı yapı çıkar.
Release aşamasında bu değişmez yapı, çalışacağı ortamın ayarlarıyla birleştirilir. Veritabanı adresi, gizli anahtarlar, API tokenları gibi ortama özgü değerler bu aşamada eklenir. Her release benzersiz bir kimlik alır (örneğin bir sürüm numarası ya da zaman damgası). Bu sayede bir sorun çıktığında önceki sürüme geri dönmek (rollback) hızlı ve güvenli olur; yeniden derlemeye gerek kalmaz, sadece bir önceki release'i tekrar çalıştırırsınız.
Run aşamasında seçilen release sunucuda başlatılır. Uygulama süreci ayağa kalkar, ağ portunu dinlemeye başlar ve gelen istekleri karşılamaya hazır hale gelir. Bu aşamada mümkün olduğunca az şey olmalıdır; asıl ağır iş build aşamasında bitmiş olmalıdır ki uygulama hızlı ve öngörülebilir biçimde başlasın.
Bu üç aşamanın ayrı tutulmasının pratik faydası şudur: build bir kez yapılır, aynı yapı test, hazırlık (staging) ve üretim ortamlarında tekrar tekrar çalıştırılabilir. Böylece "benim makinemde çalışıyordu ama sunucuda çalışmadı" sorunu büyük ölçüde ortadan kalkar, çünkü çalışan şey her yerde aynı yapıdır.
Git Push ile Deploy: Adım Adım
Modern deploy'un en yaygın biçimi, git deposuna yapılan bir push'un tüm süreci otomatik tetiklemesidir. Bu yaklaşımda deploy ayrı bir el işi değildir; kodunuzu göndermeniz yeterlidir, gerisini platform yürütür. Tipik bir git push deploy akışı şöyle işler:
1. Kodu depoya gönderin
Yerel değişikliklerinizi commit edip bağlı olduğunuz dala gönderirsiniz. Bu, tüm sürecin başlangıç sinyalidir.
git add .
git commit -m "Ödeme akışına yeni doğrulama eklendi"
git push origin main2. Platform değişikliği algılar ve build başlatır
Push tamamlanır tamamlanmaz platform yeni bir commit olduğunu görür ve build aşamasını tetikler. Kaynak kodunuz otomatik olarak çözümlenir, bağımlılıklar yüklenir ve çalıştırılabilir yapı üretilir. Buildpack tabanlı sistemlerde dilin ve çerçevenin ne olduğu otomatik algılanır; özel bir yapılandırma isterseniz kendi Dockerfile dosyanızı da kullanabilirsiniz.
3. Release oluşturulur
Üretilen yapı, ortam değişkenlerinizle birleştirilir ve numaralandırılmış bir sürüm haline gelir. Bu sürüm kaydedilir, böylece ileride bir soruna karşı geri dönüş noktası olarak durur.
4. Yeni sürüm kesintisiz devreye alınır
Platform yeni sürümü ayağa kaldırır ve sağlıklı çalıştığını doğruladıktan sonra trafiği eskisinden yenisine kaydırır. Bu genellikle sıfır kesinti (zero-downtime) ile yapılır: eski sürüm istekleri karşılamaya devam ederken yeni sürüm hazırlanır, hazır olduğu an devir gerçekleşir. Kullanıcı bir kesinti hissetmez.
Bu akışta dikkat edilmesi gereken tek kritik nokta, uygulamanızın doğru adresi ve portu dinlemesidir. Uygulama, platformun kendisine bildirdiği PORT ortam değişkenini okumalı ve 0.0.0.0 üzerinden bağlanmalıdır. localhost ya da sabit bir portu dinleyen bir uygulamaya platform ulaşamaz; ilk deploy denemelerinin en sık başarısızlık nedeni budur. Node.js'te bu değer process.env.PORT üzerinden okunur:
const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0", () => {
console.log(`Uygulama ${port} portunda çalışıyor`);
});Aynı desen bütün dillerde geçerlidir: Python'da os.environ["PORT"], Go'da os.Getenv("PORT"). Değişkeni okuyup 0.0.0.0 üzerinden dinlemeniz, uygulamanızın deploy edilebilir olması için çoğu zaman tek gereken uyarlamadır.
Ortam Değişkenleri, Domain ve Loglar
Bir uygulamayı yalnızca çalıştırmak yetmez; onu yapılandırmak, erişilebilir kılmak ve çalışırken izleyebilmek gerekir. Deploy sürecinin ayrılmaz üç parçası ortam değişkenleri, alan adı ve loglardır.
Ortam değişkenleri (environment variables) uygulamanızın koddan bağımsız ayarlarıdır: veritabanı bağlantı adresi, API anahtarları, gizli tokenlar, özellik bayrakları. Twelve-Factor metodolojisinin yapılandırma ilkesi bu değerlerin asla kaynak koda gömülmemesini, ortamdan okunmasını önerir. Bunun iki sebebi vardır: gizli bir anahtarı koda yazarsanız depoyu gören herkes onu görür ve aynı kodu farklı ortamlarda (test, üretim) farklı ayarlarla çalıştıramazsınız. Gizli anahtarlarınızı ortam değişkeni olarak tanımlar, kodda ise yalnızca process.env.DATABASE_URL gibi okursunuz.
Alan adı ve HTTPS, uygulamanızın dış dünyadaki adresidir. Deploy sonrası platform genellikle geçici bir adres verir; ardından kendi alan adınızı (uygulamam.com) bağlarsınız. Kalıcı ve güvenli erişim için HTTPS sertifikası şarttır; modern platformlarda bu sertifika alan adını bağladığınız anda otomatik gelir ve süresi dolmadan kendini yeniler, dolayısıyla elle sertifika yönetmezsiniz.
Loglar (kayıtlar), uygulamanız çalışırken ne yaptığını gösteren metin akışıdır. Bir deploy başarısız olduğunda ya da uygulama beklenmedik davrandığında ilk bakılacak yer loglardır. İyi bir uygulama önemli olayları ve hataları standart çıktıya (stdout) yazar; platform bu akışı toplayıp size gösterir. Deploy sonrası ilk yapmanız gereken şey çoğu zaman logları açıp uygulamanın "dinlemeye başladı" mesajını görmektir.
Bu üç unsur birlikte deploy'un görünmeyen ama vazgeçilmez altyapısını oluşturur. Sadece kodu sunucuya koymak deploy değildir; onu doğru ayarlarla besleyip, erişilebilir kılıp, gözlemlenebilir hale getirmek deploy'u tamamlar.
Geleneksel Deploy ile Modern Deploy Arasındaki Fark
Deploy'un nasıl yapıldığı son on yılda köklü biçimde değişti. Eskiden bir uygulamayı canlıya almak, birçok elle yapılan adımın hatasız sıralanmasını gerektiren, saatler sürebilen ve riskli bir işti. Bugün aynı iş çoğunlukla tek bir git push ile birkaç dakikada tamamlanır. İkisi arasındaki farkı görmek, modern yaklaşımın neden tercih edildiğini açıklar.
| Konu | Geleneksel deploy | Modern deploy (git push / PaaS) |
|---|---|---|
| Tetikleme | Elle, SSH ile sunucuya bağlanıp komut çalıştırma | git push ile otomatik |
| Sunucu hazırlığı | İşletim sistemi, çalışma zamanı, web sunucusu elle kurulur | Platform tarafından yönetilir |
| Build | Sunucu üzerinde elle veya betikle | Otomatik, izole ve tekrarlanabilir |
| Kesinti | Genellikle deploy sırasında kısa kesinti olur | Sıfır kesinti (zero-downtime) |
| Geri dönüş | Elle, riskli, çoğu zaman yeniden derleme | Tek tıkla önceki sürüme dönüş |
| HTTPS sertifikası | Elle kurulur ve yenilenir | Otomatik gelir ve yenilenir |
| Ölçekleme | Yeni sunucu kurup yük dengeleyici eklenir | Otomatik yatay ölçekleme |
| Hata riski | Yüksek; her adım elle | Düşük; süreç otomatik ve tutarlı |
Geleneksel yöntemde tipik bir deploy şöyle işlerdi: sunucuya SSH ile bağlanır, kodu git pull ya da rsync ile çeker, bağımlılıkları yükler, derleme betiğini çalıştırır, servisi yeniden başlatır ve web sunucusu ayarlarını elle güncellerdiniz. Bu adımlardan biri atlanır ya da yanlış yapılırsa uygulama bozuk bir halde canlıya çıkabilirdi. Üstelik deploy sırasında uygulama kısa süreliğine erişilemez olurdu.
Modern yaklaşımda bu adımların tamamı otomatikleşir. Siz yalnızca kodu gönderirsiniz; build, release, run, sertifika ve ölçekleme platformun sorumluluğundadır. Bu, hem hata olasılığını düşürür hem de deploy'u öyle sıradan bir işe dönüştürür ki günde onlarca kez güvenle deploy yapabilirsiniz. Bu ikinci yaklaşımın adı sürekli teslim (Continuous Delivery / CD) yaklaşımıdır ve modern yazılım geliştirmenin standardı haline gelmiştir.
Sunucu türlerinin ve kiralamanın deploy sürecine etkisini daha ayrıntılı görmek isterseniz VPS, VDS ve bulut sunucu farkları yazımıza bakabilirsiniz.
Sunucu Yönetmeden Deploy: Out Plane
Deploy'un modern biçimini pratikte deneyimlemenin en hızlı yolu, altyapıyı sizin yerinize yöneten bir uygulama platformu (PaaS) kullanmaktır. Out Plane tam olarak bunu yapar: container tabanlı uygulamalarınızı sunucu ya da YAML yönetmeden canlıya alırsınız.
Bir uygulamayı deploy etmek şu adımlarla işler:
- Deponuzu bağlayın. GitHub deponuzu seçersiniz. Platform kodunuzu Cloud Native Buildpacks ile otomatik algılayıp derler; özel bir Dockerfile kullanmak isterseniz o da desteklenir.
- Portu doğru dinleyin. Uygulamanız
0.0.0.0adresini ve platformun verdiğiPORTdeğişkenini dinlemelidir. Bu tek uyarlama, uygulamanızı deploy edilebilir kılar. - Push ile yayına alın. Bağlı dalınıza her push, yeni bir sürümü otomatik ve kesintisiz olarak canlıya alır.
Node.js, Python, Go, Java, Ruby, PHP, .NET ve Rust doğrudan desteklenir. Managed PostgreSQL'i (otomatik yedek, point-in-time recovery, read replica ve bağlantı havuzu ile) aynı platformdan kurarsınız; Redis gibi başka bir motora ihtiyaç duyduğunuzda onu kalıcı volume'lu bir container içinde kendiniz çalıştırırsınız. Kendi alan adınızı eklediğinizde HTTPS sertifikası otomatik gelir. Ortam değişkenleri, kalıcı volume, TCP servis, API token ve tarayıcı üzerinden terminal erişimi de kutunun içinde gelir; loglarınızı konsoldan canlı izlersiniz.
Trafiğiniz arttığında birden çok instance çalıştırıp bir yük dengeleyici arkasında yatay olarak ölçeklenirsiniz; instance sayısını kendiniz belirler ve ayarlarsınız. Instance'lar sürekli açık kaldığından cold start yaşamazsınız. Uygulamalarınızı Nuremberg ya da Helsinki bölgesinde barındırabilir, AB veri yerleşimi gereken işler için uygun bölgeyi seçebilirsiniz.
Maliyet tarafında kalıcı ücretsiz bir Hobby katmanı vardır; tek bir uygulama çalıştırır ve aylık minimum ödeme yoktur. Yeni hesaplar ayrıca 20 dolar kredi alır ve başlamak için kart bilgisi gerekmez. Daha fazlasına ihtiyaç duyduğunuzda ücretli katman kullandıkça öde (pay-as-you-go) mantığıyla faturalandırır; güncel oranları fiyatlandırma sayfasında görebilirsiniz.
Sonuç
Deploy, yazdığınız kodu kendi makinenizden çıkarıp gerçek kullanıcıların erişebileceği canlı bir ortama taşıma sürecidir. Perde arkasında build, release ve run olmak üzere üç aşamadan geçer ve bu aşamaların ayrı tutulması, sürümler arası geçişi ve geri dönüşü güvenli kılar.
Geleneksel deploy elle, yavaş ve hataya açık bir işken, modern deploy tek bir git push ile başlayan otomatik bir akıştır. Ortam değişkenleri uygulamayı yapılandırır, alan adı ve HTTPS onu erişilebilir kılar, loglar ise çalışırken gözlemlenebilir tutar. Bu üçünü doğru kurduğunuzda deploy artık korkulan bir tören değil, günde defalarca güvenle tekrarladığınız sıradan bir işlem olur.
Kendi uygulamanızı bugün canlıya almak isterseniz Out Plane konsolundan başlayabilirsiniz: 20 dolar başlangıç kredisi ve kart bilgisi olmadan.
Sıkça Sorulan Sorular
Deploy ne demek?
Deploy, yazdığınız kodu geliştirme ortamından çıkarıp gerçek kullanıcıların erişebileceği canlı bir sunucuya taşıma işlemidir. Türkçede dağıtım ya da yayına alma olarak geçer. Yalnızca sizin bilgisayarınızda çalışan bir uygulamayı internette herkesin erişebileceği bir hizmete dönüştürmenin adıdır.
Deploy ile build aynı şey mi?
Hayır, build deploy'un yalnızca bir aşamasıdır. Build, kaynak kodu çalıştırılabilir bir pakete dönüştürür. Deploy ise bu paketi ortam ayarlarıyla birleştirip (release) sunucuda başlatmayı (run) da kapsayan daha geniş süreçtir. Yani her deploy bir build içerir, ama build tek başına deploy değildir.
Git push ile deploy nasıl çalışır?
Kodunuzu bağlı olduğunuz dala push ettiğinizde platform bu değişikliği algılar ve deploy sürecini otomatik başlatır. Build, release ve kesintisiz devreye alma adımları sizin müdahaleniz olmadan sırayla çalışır. Uygulamanızın PORT değişkenini okuyup 0.0.0.0 dinlemesi çoğu zaman tek gereken şarttır.
Deploy sırasında sitem erişilemez mi olur?
Modern platformlarda hayır. Sıfır kesinti (zero-downtime) tekniğiyle eski sürüm istekleri karşılamaya devam ederken yeni sürüm hazırlanır ve ancak sağlıklı çalıştığı doğrulandıktan sonra trafik ona kaydırılır. Kullanıcı bir kesinti hissetmez. Geleneksel elle deploy'da ise genellikle kısa bir kesinti yaşanır.
Deploy hata verdiğinde ne yapmalıyım?
İlk olarak logları açıp hata mesajını okuyun; deploy sorunlarının çoğu burada görünür. En sık karşılaşılan neden, uygulamanın yanlış port veya adres dinlemesidir; PORT değişkenini okuyup 0.0.0.0 dinlediğinizden emin olun. Eksik ortam değişkeni ve bağımlılık sorunları da sık görülür. Sorun devam ederse bir önceki çalışan sürüme geri dönebilirsiniz.
Deploy yapmak için sunucu yönetmeyi bilmem gerekir mi?
Hayır. Uygulama platformları (PaaS) sunucu kurulumunu, işletim sistemi bakımını ve web sunucusu yapılandırmasını sizin yerinize yönetir. GitHub deponuzu bağlayıp push yaparsınız, deploy otomatik gerçekleşir. Linux, SSH veya sunucu güvenliği bilmeden de uygulamanızı canlıya alabilirsiniz.
Ortam değişkenlerini neden koda yazmamalıyım?
Gizli anahtar, veritabanı adresi gibi ayarları koda yazarsanız iki sorun çıkar: depoyu gören herkes gizli bilgilerinizi görür ve aynı kodu farklı ortamlarda farklı ayarlarla çalıştıramazsınız. Bu değerleri ortam değişkeni olarak tanımlar, kodda yalnızca okursunuz. Bu, uygulamayı hem güvenli hem taşınabilir kılar.
Ücretsiz deploy yapabilir miyim?
Evet. Out Plane'in kalıcı ücretsiz Hobby katmanı tek bir uygulama çalıştırır ve aylık minimum ödeme yoktur. Yeni hesaplar ayrıca 20 dolar kredi alır ve başlamak için kart bilgisi gerekmez. Böylece gerçek bir uygulamayı ödeme yapmadan konsoldan canlıya alıp deneyebilirsiniz.