Google SRE Bölüm 8 — Release Engineering

Chapter 7'de otomasyonun evrimini konuşmuştuk. Chapter 8, bu evrimin en somut uygulama alanlarından birine, yazılımı üretime çıkarma sürecine, kendi başına bir disiplin gözüyle bakıyor: Release Engineering.

Release Engineering Neden Ayrı Bir Disiplin?

Google, çoğu şirkette release sürecinin gelişigüzel işlediğini söylüyor. Her geliştirici kendi bildiği gibi deploy ediyor ve bu ölçek büyüdükçe ciddi risk taşıyor. Google'da Release Engineer'lar, software engineer'lardan ayrı ama onlarla yakın çalışan bir rol; build ve deploy süreçlerinin güvenilirliğinden ve tekrarlanabilirliğinden sorumlular.

Dört Temel İlke

Self-service model, geliştirici ekipler release engineer'lara sürekli bağımlı olmadan kendi release'lerini yapabilmeli. Release engineer'ın işi süreç kurmak, her release'i elle yönetmek değil.

High velocity, sık release yapmak aslında riski azaltıyor çünkü her release'deki değişiklik miktarı küçülüyor. Az sık, büyük release'ler daha risklidir. Bu, Chapter 3'teki error budget mantığıyla doğrudan bağlantılı. Sık, küçük değişiklikler bütçeyi daha öngörülebilir bir şekilde tüketiyor.

Hermetic builds, bir build'in sonucu, hangi makinede ve ne zaman çalıştırılırsa çalıştırılsın aynı olmalı. Dışarıdan bir bağımlılık, örneğin sistem üzerindeki global bir kütüphane sürümü, build'i etkilememeli. Bu, "benim makinemde çalışıyordu" sorununun kökten çözümü.

Policies and procedures, kim neyi deploy edebilir, hangi onaylar gerekli, değişiklik nasıl izlenir gibi kuralların net ve tutarlı olması gerekiyor.

Konfigürasyon da Bir Release

Bölümün altını çizdiği bir başka nokta şu: konfigürasyon, kod kadar dikkatli yönetilmeli. Config değişiklikleri de bir release gibi düşünülmeli çünkü pratikte pek çok kesinti kod değişikliğinden değil, config değişikliğinden kaynaklanıyor.

Sonuç

Chapter 8, Chapter 7'nin doğal bir devamı gibi okunabilir. Release sürecinin otomasyonu, toil'i azaltma ve güvenilir tekrarlanabilirlik temalarının somut bir uygulama alanı. Google'ın kendi iç aracı Rapid, build, test ve deploy'u birleşik bir pipeline'da yöneten sistem olarak burada örnek gösteriliyor.

2026 Merceğinden: Dört İlke Artık Hazır Paket

Hermetic builds fikri bugün container'lar ve reproducible build pratikleriyle endüstri standardına dönüştü. Kubernetes ve Terraform dünyasında immutable image'lar ve declarative config, bu prensibin doğrudan uygulaması. Bir image bir kere build edildikten sonra, hangi ortamda çalıştırılırsa çalıştırılsın aynı davranıyor.

Asıl ilginç değişim şurada: On yıl önce bu dört ilkeyi (self-service, high velocity, hermetic builds, policy) hayata geçirmek, Google gibi bir şirkete özel, ciddi bir mühendislik yatırımı gerektiriyordu. Bugün GitHub Actions, ArgoCD, Flux gibi araçlar bu ilkeleri neredeyse hazır paket olarak sunuyor. Bir geliştirici, birkaç YAML dosyasıyla self-service, tekrarlanabilir, politika kontrollü bir pipeline kurabiliyor; bu on yıl önce imkansız değildi ama çok daha pahalıydı.

"Config değişiklikleri de release'dir" fikri de bugün GitOps'un temel felsefesiyle birebir örtüşüyor: Her şey kod olarak tutulur, her değişiklik review'dan geçer, her değişiklik geri alınabilir. Aslında GitOps, bu bölümün on yıl önce çizdiği çerçevenin bir sonraki nesli gibi düşünülebilir; farkı, artık bunun sadece Google'ın değil, herkesin erişebildiği bir standart olması.

Sıradaki durakta Chapter 9'a geçiyoruz: Simplicity, Part II'nin son bölümü.

Teşekkür ederim.