Yazılım Ekipleri Dağıtımlar Üzerindeki Kontrolü Nasıl Kaybeder?

Yazılım geliştirirken, dağıtım sürecinin ilk günden itibaren önem taşıdığını bilirsiniz. Bu sadece "ileride halledilir" bir DevOps sorunu değil; ürününüzün kararlılığını, hata durumlarından kurtulma hızınızı ve ekip olarak yaptığınız değişikliklere olan güveninizi doğrudan etkiler.

Ancak çoğu ekip, teoride bunu kabul etse de pratikte süreci karmaşık bir yamalı bohça gibi yönetmeye başlar: CI işlemleri bir yerde, Slack bildirimleri başka bir yerde, geçici bir çözümse kalıcı hale gelir.

Sistem çalışır — ta ki çalışmadığı an gelene kadar.

Ve bir hata meydana geldiğinde, cevaplanmaya çalışılan aynı soru yine gündeme gelir: "Tam olarak ne oldu?"

Eğer bu sizin için tanıdık geliyorsa, doğru yerdesiniz.

CI ve CD aynı şey değil — ve asla olmamalı

On yıldan uzun süredir teknoloji ürünleri geliştiriyor, ekipleri yönetiyor ve erken aşama borulardan gerçek operasyonel baskı altında çalışan üretim sistemlerine kadar tüm dağıtım sürecini deneyimliyorum. Bu süreçte, CI (Sürekli Entegrasyon) ile CD (Sürekli Dağıtım) arasındaki farkın ne kadar kritik olduğunu görmekten kaçınamadım.

Ekipler genellikle CI platformlarını her şeyi yapmanın varsayılan yeri olarak kullanmaya başlar: kod derleme, test etme, paket oluşturma, dağıtım, tanıtma ve hatta bazen geri alma işlemlerini bile aynı sistemde gerçekleştirir. Başlangıçta verimliymiş gibi görünür — kaynak kod zaten GitHub ya da GitLab’de, boru hattı tanımları kodun yanında, çalıştırıcılar hazır. Peki, dağıtım ve yayın orkestrasyonunu da aynı sistemde neden yönetmiyoruz ki?

Çünkü başlangıçtaki kolaylık, ölçeklendikçe bağımlılığa dönüşür.

CI ve CD birbiriyle ilişkili olabilir, ancak aynı sorumluluk alanına girmezler. CI, değişiklikleri doğrulamakla ilgilidir — kod derlemek, testleri çalıştırmak, bir öğe üretmek, commit’in sağlıklı olduğunu onaylamak. Tek bir soruya yanıt arar: "Bu değişiklik geçerli mi?"

CD ise kontrollü değişiklik yayılımıyla ilgilidir — yayın adayını seçmek, nereye gideceğine karar vermek, onay akışını tanımlamak, ortamlar arasında tanıtmak, rol tabanlı erişimi uygulamak, denetim geçmişini yakalamak, güvenli bir şekilde geri almayı yönetmek. Tamamen farklı bir soruya yanıt verir: "Hangi versiyon, nerede, ne zaman dağıtıldı ve sonra ne oldu?"

Bu farklı sorulara farklı sistemler gereklidir.

CI’yi dağıtımlar için kullanmanın gizli maliyeti

GitHub Actions ya da GitLab boru hatlarını dağıtımlar için kullanmak yanlış değildir — aslında başlangıç için en hızlı yol olabilir. Ancak dağıtım mantığı CI’nin içinde yaşadığında, çeşitli sorunlar birikmeye başlar.

1. Dağıtım süreci kaynağınıza bağımlı hale gelir

Eğer CI platformunuz aksarsa, dağıtım süreciniz de aksar. GitHub’un geçmiş olay kayıtları, Actions işlerinin başarısız olduğu ya da geciktiği (bazen aynı pencerede çekme isteklerini ve API isteklerini de etkileyen) birkaç olayı gösterir.

Tüm yapılarınız, onaylarınız ve üretim dağıtımlarınız aynı platforma bağlıysa, bir kesinti hem geliştirmeyi hem de dağıtımı aynı anda durdurur. Sıcak bir düzeltme göndermek istediğinizde, "her şey tek yerde" avantaj gibi görünmekten çıkar — operasyonel bir bağımlılığa dönüşür.

2. CI boru hatları yürütme konusunda iyidir; yayın yönetişimi konusunda değil

Boru hatları işleri çalıştırmak için iyi tasarlanmıştır. Ancak yayın niyetinin kayıt sistemi olmak için doğal değildir. Evet, onayları boru hattına ekleyebilirsiniz. Evet, ortam tanıtımını YAML’da modelleyebilirsiniz. Evet, geri alma mantığını komut dosyalarında kodlayabilirsiniz. Ancak zamanla ekipler, CI’nin temelde cevaplamak için inşa edilmediği soruları sormaya başlar:

• - Hangi versiyon staging’e onaylandı?
• - Üretime tanıtım için kim, ne zaman onay verdi?
• - Yayın çıkmadan önce QA onayı alındı mı?
• - Önceki başarılı versiyon hangisiydi?
• - Dağıtım sağlık kontrolü başarısız olursa otomatik olarak geri alabilir miyiz?

Bu noktada dağıtım, "sadece başka bir iş" olmaktan çıkar ve boru hattının tasarlanmadığı bir operasyonel iş akışına dönüşür.

3. Dağıtım mantığı, depo olaylarına çok sıkı bağlı hale gelir

Çoğu CI odaklı dağıtım kalıbı, depo tetiklemelerine dayanır: dalın itilmesi, ana dalın birleştirilmesi, etiket oluşturulması. Bu, dağıtım süreciniz basit olduğunda işe yarar. Ancak ekipler zamanla boru hatlarının tasarlanmadığı şeyleri istemeye başlar — bir kez inşa et, birçok kez dağıt; aynı öğeyi staging’den üretime yeniden inşa etmeden tanıt; operasyonların kod tabanına dokunmadan dağıtım yapmasına izin ver; yeniden inşa etmeden geri al. Boru hattı karşı koymaya başlar. Bu sürtüşme genellikle dağıtımın CI’nin sınırlarını aştığının ilk işaretidir.

Saat 02.00’deki gerçek maliyet

Gerçek maliyet, üretimde bir olay meydana geldiğinde ve her dakikanın önemli olduğu anda görünür hale gelir. İşte ilk on dakika içinde sorulan sorular:

• - Üretimde çalışan versiyonu kim dağıttı?
• - Bu versiyon üretime tanıtılmadan önce QA onayı alındı mı?
• - Bu dağıtımdan önce bilinen son kararlı versiyon hangisiydi?
• - Bir sonraki beş dakika içinde yeniden inşa etmeden geri alabilir miyiz?

CI odaklı dağıtımlar bu sorulara yanıt veremediğinde (çünkü bilgi boru hattı günlüklerine, Slack konuşmalarına ve bireysel hafızalara dağılmış durumda), olayın çözülmesi daha uzun sürer.

Teknoloji ürünleri geliştirme ekipleri için her bir duruş dakikası doğrudan kullanıcıya yansıyan bir etkiye sahiptir. Ayrıca daha az görünür bir maliyet de var: ekip, neden yavaşladığını anlamadan yavaşlar.

Geri alma işlemi burada özel bir önem taşır. Birçok CI odaklı kurulumda, geri alma tanımlı bir operasyon değildir. Bir telaştır:

• - Eski etiketi bul
• - Boru hattını yeniden çalıştır
• - Hiçbir şeyin kaymamış olmasını um
• - Geçen sefer kullanılan parametreleri yeniden oluştur

Bu, baskı altında yapılan bir doğaçlamadır. Bir yayın sistemi, geri almayı birinci sınıf bir yetenek olarak görmelidir — test edilmiş, öngörülebilir ve hızlı.

Çünkü saat 02.00’de netlik her şeyden önemlidir.

Bağımsız sistemler, paylaşılan boru hattı

Çözüm, mevcut CI kurulumunuzu değiştirmek değildir. GitHub Actions güçlüdür, GitLab CI iyi tasarlanmıştır ve Jenkins birçok organizasyon için hala derinlemesine kullanışlıdır. Bu bir araç tartışması değil, bir mimari argümandır.

CI’yi olduğu yerde bırakın — kod derleme, test etme, paket oluşturma, paket doğrulama.

Ancak CD’yi bağımsız bir sistemde yönetin — yayın adaylarını yönetme, onay akışlarını uygulama, ortamlar arasında güvenli bir şekilde tanıtma, denetim geçmişini yakalama, hızlı ve güvenilir geri alma yeteneklerini sağlama.

Bu şekilde, CI’nin sunduğu hız ve verimliliği korurken, CD’nin gerektirdiği netlik, güvenlik ve ölçeklenebilirliği kazanırsınız. Sonuçta, kullanıcılarınıza güvenilir bir ürün sunmak için hem geliştirme hem de dağıtım süreçlerinde kontrole sahip olmanız gerekir — ve bu kontrole gece geç saatlerde ihtiyacınız olabilir.