Özel yazılım teslim edip “sunucuya kopyaladık” demek 2026’da yetmiyor. Müşteri güncelleme ister, güvenlik yaması gelir, gece 02:00’de bir entegrasyon düşer. DevOps burada moda kelime değil; yayın ve geri alma disiplinidir.
Bizde neyi kastediyoruz?
- Kaynak kontrolü ve gözden geçirme
- CI ile test / build (Jenkins veya benzeri pipeline’lar)
- Konteyner ve mümkünse orchestration (Docker / Kubernetes)
- Ortam ayrımı (geliştirme / staging / production)
- Log, izleme ve yedekleme
Pipeline’da gerçekte ne çalışıyor?
“CI ile test/build” tek bir tık değil, art arda gelen kontrol adımları demek. Bir değişiklik push edildiğinde pipeline sırasıyla şunları yapar:
- Lint ve statik analiz: Kod stiline ve bilinen hata desenlerine bakılır — insan gözden geçirmesinden önce ucuz hatalar elenir.
- Otomatik testler: Birim ve entegrasyon testleri koşar; kırık bir değişiklik staging’e bile gitmeden yakalanır.
- Build ve imaj oluşturma: Uygulama derlenir, Docker imajı üretilir ve etiketlenir (versiyon/commit ile izlenebilir olması için).
- Dağıtım (deploy): İmaj hedef ortama (staging veya production) otomatik ya da onaylı bir adımla gönderilir.
Bu sıralama önemli: her adım bir öncekini geçmeden ilerlemez. Yani “test geçmeyen kod production’a çıkamaz” kuralı insan hafızasına değil, pipeline’a yazılıdır.
Sıfır kesintili (zero-downtime) yayın nasıl sağlanır?
Kubernetes ile çalışan bir serviste yeni sürüm, eski sürümü aniden kapatıp yenisini açmaz. Sağlıklı (ready) olduğu doğrulanan yeni pod’lar kademeli olarak devreye alınır, eski pod’lar da yeni sürüm trafiği taşımaya başladıktan sonra kapatılır (rolling update). Bunun çalışması için servisin bir “readiness” ve “liveness” sinyali vermesi gerekir — yani “hazırım, trafik gönderebilirsin” ve “hâlâ ayaktayım” diyebilmesi. Bu sinyaller yoksa orchestration katmanı kör dolaşır; bozuk bir sürüm bile “çalışıyor” sanılıp trafiğe açılabilir.
Bir şey kırılırsa: rollback ve izleme
Yayın disiplini sadece ileri gitmekle ilgili değil, hızlı geri dönebilmekle de ilgili. İmajlar commit/versiyon etiketiyle saklandığı için bir önceki çalışan sürüme dönmek yeni bir “hotfix” yazmayı beklemeden dakikalar içinde mümkün olur. Bunu anlamlı kılan şey ise ne zaman geri dönülmesi gerektiğini bilmek: log toplama, temel uptime/health-check izleme ve hata oranı takibi olmadan bir sorunu müşteri fark etmeden yakalayamazsınız.
Burada da abartıya kaçmıyoruz: her proje için ayrı bir gözlemlenebilirlik (observability) yığını kurmuyoruz. Trafiği ve riski düşük bir vitrin sitede temel uptime kontrolü yeterliyken; ödeme akışı olan bir e-ticaret sisteminde (OYPES gibi) hata izleme ve alarm eşiği daha sıkı tutuluyor.
Hangi projelerde fark eder?
Çok kiracılı e-ticaret (OYPES gibi), abonelik satış siteleri, B2B portallar, mobil backend’ler. Tek sayfalık vitrin sitede “basit publish” yeterli olabilir; operasyonel üründe değil.
Müşteriye ne vaat ediyoruz?
Her projeye K8s cluster satmıyoruz. Kapsama göre sade ama güvenli bir yayın yolu kuruyoruz: kırıldığında geri alınabilir, güncellemesi tekrarlanabilir olsun.
Yorum (0)
Bu yazı için henüz yorum bulunmuyor.