Kodunuzu gönderdiğiniz an ile o kodun gerçek kullanıcılarla buluştuğu an arasında geçen süreci hiç merak ettiniz mi? Yazılım dünyasında 'deploy' süreci, çoğu zaman basit bir işlem gibi görünse de aslında arka planda devasa bir mekanizmanın işlediği karmaşık bir zincirdir. Build süreçleri, artefaktlar, veritabanı migrasyonları ve sağlık kontrolleri... İşte modern yazılım geliştirme süreçlerinde üretim ortamına (production) dağıtımın perde arkası.
Koddan Çalışan Uygulamaya: Build Süreci
Bir dağıtım işlemi, kaynak kodunuzu olduğu gibi sunucuya göndermez. Kodunuzun sunucuda çalışabilir bir hale gelmesi için 'build' (derleme/paketleme) aşamasından geçmesi gerekir. Bu aşamada:
Artefakt: Zaman İçinde Dondurulmuş Tek Sürüm
Build işleminin çıktısı bir 'artefakt'tır. Bu bir container imajı veya sıkıştırılmış bir binary olabilir. Kritik olan nokta, test edilen kodun aynısının canlıya çıkmasıdır. Süreç içinde tekrar build almak, farklı bağımlılıkların devreye girmesine neden olabilir; bu da 'staging ortamında çalışıyordu ama prod'da patladı' cümlesinin ana sebebidir.
Veritabanı Migrasyonları: En Riskli Adım
Kod değiştiğinde veritabanı şeması da genellikle değişmek zorundadır. Ancak veritabanı, koddan farklı olarak 'geri alınması' zor bir alandır. Başarılı bir dağıtımda migrasyonlar, 'geriye dönük uyumlu' (backwards-compatible) olacak şekilde tasarlanmalıdır. Yeni sütun eklemek gibi işlemler, eski ve yeni kodun aynı anda çalışabildiği bir geçiş dönemine imkan tanımalıdır.
Sağlık Kontrolleri (Health Checks)
Uygulama yayına alındığında platform ona hemen güvenmez. Readiness (trafik almaya hazır mı?) ve Liveness (hala çalışıyor mu?) kontrolleri ile uygulamanın nabzı sürekli ölçülür. Bu kontroller, hatalı bir sürümün tüm trafiği bozmasını engelleyen birer güvenlik bariyeridir.
Rolling Updates ve Rollback Stratejileri
Canlı trafikte sıfır kesintiyle güncelleme yapmanın yolu 'rolling update' yani kademeli geçiştir. Uygulamanın kopyaları birer birer yeni sürümle değiştirilir. Eğer her şey yolunda gitmezse, 'rollback' (geri alma) süreci devreye girer. Başarılı bir sistemde rollback, önceki çalışan artefaktın saniyeler içinde geri yüklenmesidir.
PaaS (Platform as a Service) Kullanmalı mıyız?
Birçok ekip, kendi dağıtım altyapısını kurmanın bir 'gurur kaynağı' olduğunu düşünür. Ancak bu, aslında müşteriye değer katmayan, sadece bakım gerektiren ikinci bir ürün geliştirmekle eşdeğerdir. Eğer bir startup veya ürün odaklı bir ekipseniz, bu karmaşık süreçleri yönetmek için bir PaaS kullanmak, mühendislik kapasitenizi asıl işinize yani ürününüze odaklamanızı sağlar.
Ne Zaman Kendi Altyapınızı Kurmalısınız?
Özetle; 'Kendi dağıtım sistemimizi kurduk' demek artık bir başarı değil, gereksiz bir operasyonel yük olabilir. Mühendislerinizi kod yazmaya, altyapıyı ise bu işin uzmanı olan platformlara bırakın.
Koddan Çalışan Uygulamaya: Build Süreci
Bir dağıtım işlemi, kaynak kodunuzu olduğu gibi sunucuya göndermez. Kodunuzun sunucuda çalışabilir bir hale gelmesi için 'build' (derleme/paketleme) aşamasından geçmesi gerekir. Bu aşamada:
- Diller (Java, Go, Python vb.) derlenir veya paketlenir.
- Bağımlılıklar (dependencies) çözülür ve sabitlenir.
- Genellikle uygulama, her şeyiyle hazır bir 'container' imajı haline getirilir.
- Birim testleri, linting ve güvenlik taramaları çalıştırılır. Eğer bu aşamada bir hata oluşursa, dağıtım durdurulur ve hatalı kodun canlıya çıkması engellenir.
Artefakt: Zaman İçinde Dondurulmuş Tek Sürüm
Build işleminin çıktısı bir 'artefakt'tır. Bu bir container imajı veya sıkıştırılmış bir binary olabilir. Kritik olan nokta, test edilen kodun aynısının canlıya çıkmasıdır. Süreç içinde tekrar build almak, farklı bağımlılıkların devreye girmesine neden olabilir; bu da 'staging ortamında çalışıyordu ama prod'da patladı' cümlesinin ana sebebidir.
Veritabanı Migrasyonları: En Riskli Adım
Kod değiştiğinde veritabanı şeması da genellikle değişmek zorundadır. Ancak veritabanı, koddan farklı olarak 'geri alınması' zor bir alandır. Başarılı bir dağıtımda migrasyonlar, 'geriye dönük uyumlu' (backwards-compatible) olacak şekilde tasarlanmalıdır. Yeni sütun eklemek gibi işlemler, eski ve yeni kodun aynı anda çalışabildiği bir geçiş dönemine imkan tanımalıdır.
Sağlık Kontrolleri (Health Checks)
Uygulama yayına alındığında platform ona hemen güvenmez. Readiness (trafik almaya hazır mı?) ve Liveness (hala çalışıyor mu?) kontrolleri ile uygulamanın nabzı sürekli ölçülür. Bu kontroller, hatalı bir sürümün tüm trafiği bozmasını engelleyen birer güvenlik bariyeridir.
Rolling Updates ve Rollback Stratejileri
Canlı trafikte sıfır kesintiyle güncelleme yapmanın yolu 'rolling update' yani kademeli geçiştir. Uygulamanın kopyaları birer birer yeni sürümle değiştirilir. Eğer her şey yolunda gitmezse, 'rollback' (geri alma) süreci devreye girer. Başarılı bir sistemde rollback, önceki çalışan artefaktın saniyeler içinde geri yüklenmesidir.
PaaS (Platform as a Service) Kullanmalı mıyız?
Birçok ekip, kendi dağıtım altyapısını kurmanın bir 'gurur kaynağı' olduğunu düşünür. Ancak bu, aslında müşteriye değer katmayan, sadece bakım gerektiren ikinci bir ürün geliştirmekle eşdeğerdir. Eğer bir startup veya ürün odaklı bir ekipseniz, bu karmaşık süreçleri yönetmek için bir PaaS kullanmak, mühendislik kapasitenizi asıl işinize yani ürününüze odaklamanızı sağlar.
Ne Zaman Kendi Altyapınızı Kurmalısınız?
- Sıkı uyumluluk ve denetim gereksinimleri (finans/devlet) varsa.
- Dağıtım altyapısı bizzat sizin sattığınız bir ürünse.
- Çok özel donanım veya GPU kümeleri gibi standart PaaS'ların desteklemediği hibrit yapılar kullanıyorsanız.
Özetle; 'Kendi dağıtım sistemimizi kurduk' demek artık bir başarı değil, gereksiz bir operasyonel yük olabilir. Mühendislerinizi kod yazmaya, altyapıyı ise bu işin uzmanı olan platformlara bırakın.
Umarım bu rehberle o meşhur cuma akşamı çökmelerinin önüne geçeriz, ellerine sağlık demeyeyim de "klavyene zeval gelmesin" diyeyim!