Yayına çıkmak neden korkutucu? Küçük ekipler için CI/CD ve dağıtım hattı

Yayına çıkmak korkutucu geliyorsa sebebi genelde dikkatsizlik değil, dağıtımın seyrek ve büyük olması. Ayda bir çıkan bir ekip her seferinde yüzlerce değişikliği aynı gece taşır; bir şey bozulduğunda hangi değişiklikten geldiğini bulmak saatler alır ve geri dönüş yolu çoğu zaman hiç denenmemiştir. Çözüm daha çok dikkat değil, partiyi küçültmek ve süreci otomatikleştirmek. Pratikte beş şey: teslim hızını ve kararlılığını ölçen sayılar, on dakikada geri bildirim veren bir hat, tek bir derleme çıktısının her ortama taşınması, dağıtımın yayından ayrılması ve düzenli tatbikat edilen bir geri dönüş adımı. Bunlar oturduğunda "yayın gecesi" diye bir şey kalmaz, çünkü yayın sıradan bir iş adımına döner.

Önce dört sayı, çünkü ölçmediğiniz şeyi tartışamazsınız

DORA'nın yazılım teslimi ölçütleri bu konuşmanın ortak dili. Dağıtım sıklığı, belirli bir dönemde kaç kez üretime çıktığınız. Değişiklik teslim süresi (change lead time), bir değişikliğin sürüm kontrolüne girmesiyle üretimde çalışmaya başlaması arasındaki süre. Değişiklik hata oranı (change fail rate), dağıtımlardan kaçının hemen müdahale gerektirdiği. Başarısız dağıtımdan kurtulma süresi, bozuk bir dağıtımdan sonra toparlanmanın ne kadar sürdüğü. DORA 2024'te beşinci bir ölçüt ekledi: üretimdeki bir aksaklık yüzünden yapılan plansız dağıtımların oranı, yani yeniden iş oranı (rework rate).

Bunları hesaplamak için araç satın almanız gerekmiyor. İlk üçü git etiketleri, dağıtım kayıtları ve olay listesiyle elle çıkarılabilir. Önemli olan iki grubu birlikte okumak. Hız tek başına iyi haber değil: kararlılık düşerken artan dağıtım sıklığı, sadece daha hızlı bozuyorsunuz demektir. Bir de şunu baştan söyleyin, kişi bazında raporlanmayacak. Ekip düzeyinde eğilime bakılan bir ölçüt işe yarar, performans değerlendirmesine giren bir ölçüt oyuna dönüşür.

Asıl mesele hattın değil, partinin büyüklüğü

Otomasyon kurmadan önce anlaşılması gereken şey bu. Risk dağıtım başına taşınan değişiklik miktarıyla büyür, dağıtım sayısıyla değil. DORA'nın küçük partilerle çalışma kılavuzu net bir eşik koyuyor: tamamlanması ve kontrol edilmesi bir haftadan uzun süren bir kod partisi fazla büyüktür, işler saatler ile birkaç gün arasında bitecek şekilde bölünmelidir. Dal tarafında da ölçülebilir kurallar var. DORA'nın gövde temelli geliştirme (trunk-based development) sayfası üç veya daha az aktif dal tutmayı, dalları en az günde bir kez gövdeye birleştirmeyi, kod dondurma ve ayrı entegrasyon fazlarından kaçınmayı öneriyor. Aynı sayfa tipik dal ömrünün birkaç saati geçmediğini yazıyor.

Bunun sessiz düşmanı, insan onayına dayanan ağır süreçler. DORA'nın değişiklik onayını yalınlaştırma kılavuzundaki bulgu ilk duyulduğunda ters geliyor: dış onay mercilerinin (değişiklik onay kurulu gibi) daha düşük hata oranıyla ilişkili olduğuna dair kanıt bulunamamış, ağır onay yaklaşımlarının teslim performansına olumsuz etkisi ise ölçülmüş. Mekanizma zincirin ucunda görünüyor. Onay beklemek dağıtımı geciktirir, gecikme partiyi büyütür, büyük parti riski artırır. DORA'nın önerdiği yer değişimi şu: görevler ayrılığı ilkesini ekip içi kod incelemesiyle karşılamak, hata yakalamayı sürekli test ve izlemeye bırakmak, kurula ekipler arası koordinasyon ve süreç iyileştirme rolü vermek. Hedefi de tek cümleyle koyuyorlar, normal değişiklik süreciniz acil değişiklikler için de kullanabileceğiniz kadar hızlı ve güvenilir olmalı.

On dakika kuralı 2004'ten kalma, hâlâ geçerli

Kent Beck ve Cynthia Andres, Extreme Programming Explained'in ikinci baskısında birincil pratiklerden birini şöyle tanımlıyor: tüm sistemi otomatik derleyip bütün testleri on dakikada koşturun, çünkü on dakikadan uzun süren bir derleme belirgin biçimde daha seyrek kullanılır ve geri bildirim fırsatı kaçar. Yirmi yıl sonra bu sayı hâlâ iyi bir hedef, sebebi de teknik değil davranışsal. 40 dakikalık bir hat geliştiriciyi işini biriktirmeye iter, sonuç yine büyük parti.

Pratik ayrım şöyle kurulur. Commit aşamasına derleme, birim testleri, tip kontrolü ve linter girer ve bu aşama on dakikanın altında kalır. Uçtan uca tarayıcı testleri, yük testleri ve göç provaları sonraki aşamaya, paralel koşan ayrı işlere taşınır. Bağımlılık önbelleği kurmak ve test paketini paralelleştirmek çoğu ekipte bir günlük iş; kazancı her commit'te tekrar eder.

Bir kez derleyin, aynı çıktıyı her ortama taşıyın

Her ortam için yeniden derleyen bir hat, test ettiğiniz şeyi değil ona benzeyen bir şeyi yayına verir. Doğru kalıp tek bir yapı çıktısı üretmek: imaj ya da paket bir kez derlenir, sürüm etiketi alır, aynı çıktı önce test ortamına sonra üretime terfi eder. Ortam farkları koda değil yapılandırmaya girer, yani bağlantı adresleri, anahtarlar ve özellik bayraklarına. "Test ortamında çalışıyordu" cümlesinin arkasında sıklıkla ikinci bir derlemenin farklı bir bağımlılık sürümü çekmesi vardır. Bağımlılıkları kilit dosyasıyla sabitleyin, imajları etiket yerine özet (digest) değeriyle referanslayın.

Dağıtım ile yayın aynı şey değil

Küçük ekiplerde en çok işe yarayan tekniklerden biri bu ikisini ayırmak. DORA'nın küçük partiler kılavuzu özellik bayraklarını açıkça öneriyor: yapılandırma anahtarlarıyla yeni kodun davranışını değiştirebilir, arayüz öğelerini görünür ya da gizli yapabilir, servis mantığını açıp kapatabilirsiniz. Böylece yarım kalmış bir özellik kullanıcıya görünmeden üretime alınır, buna karanlık yayın (dark launch) deniyor. Faydası doğrudan partiyi küçültmek: bitmeyen iş bir dalda haftalarca beklemez, kapalı bir bayrağın arkasında üretimde durur.

Bayrakların bedelini de yazın. Her bayrak kodda bir dallanma, test yükünde bir ikizleme demek. Kural olarak her bayrağa bir sahip ve bir son kullanma tarihi verin, tamamen açıldıktan sonra iki hafta içinde kodu temizleyin. Uzun ömürlü kalmayı hak eden tek tür, riskli bir entegrasyonu ya da ağır bir özelliği kapatmaya yarayan acil durum şalteridir.

Hattın en tehlikeli adımı veritabanı

Kod geri alınabilir, düşürülmüş bir kolon geri alınamaz. Üstelik kademeli (rolling) dağıtımda eski ve yeni sürüm bir süre aynı anda çalışır, yani şemanın ikisiyle de uyumlu olması gerekir. Yaygın çözüm genişlet/daralt (expand/contract) deseni. Önce şemayı yalnızca ekleyerek genişletirsiniz: yeni kolon gelir, eski yerinde kalır. Sonra veriyi taşıyıp kodu yeni alana geçirirsiniz. En sonda, kimsenin okumadığından emin olduğunuzda eski yapıyı düşürürsünüz. Yani tek bir kırıcı değişiklik üç ayrı dağıtıma bölünür.

İki pratik kural bunu ayakta tutuyor. Göç betiği, hâlâ çalışan eski sürümün altında sorunsuz koşabilmeli. Ve yeniden adlandırma diye bir işlem yoktur, ekle-kopyala-düşür vardır. Büyük tablolarda kilit süresini önceden ölçün; üretime yakın bir veri hacmiyle prova edilmemiş bir göç, hattaki en pahalı adımdır.

Geri dönüş bir belge değil, tatbikat

"Sorun olursa geri alırız" cümlesi hiç denenmediyse plan değil, temenni. Ölçülebilir hâli DORA'nın başarısız dağıtımdan kurtulma süresi ölçütü ve o süreyi ancak deneyerek bilirsiniz. Gerekenler kısa bir liste: önceki sürüm çıktısı hâlâ dağıtılabilir durumda olmalı, dağıtımdan sonra otomatik bir sağlık kontrolü koşmalı, kontrol başarısız olursa hat kendiliğinden önceki sürüme dönmeli, ve bunu ekipten en az iki kişi tek başına yapabilmeli. Ayda bir, iş saatinde, kasıtlı olarak geri alın. Cuma 23:00'te ilk kez denenen bir geri dönüş, çözüm değil ikinci bir olaydır.

Hat, sisteminizin en yetkili noktası

CI koşucusu (runner) pratikte üretim anahtarlarını, bulut kimliğini ve paket deposu jetonunu elinde tutar. Mart 2025'te bunun bedeli görüldü: çok kullanılan tj-actions/changed-files GitHub Action'ının etiketleri kötü niyetli bir commit'e yönlendirildi ve iş akışı günlüklerine sırlar döküldü. CISA olay için uyarı yayımladı. Ölçek de öğretici: eylemi 23 binden fazla depo kullanıyordu, Endor Labs'in incelemesine göre 218 depo gerçekten sır sızdırdı ve sızanların çoğu iş akışı bitince geçersiz olan GitHub jetonlarıydı. Hasar sınırlı kaldı, ama yöntem çalıştı.

GitHub'ın sertleştirme dokümanı üç somut önlem veriyor. Üçüncü taraf eylemleri tam uzunlukta commit SHA'sına sabitleyin; dokümanın ifadesiyle bir eylemi değiştirilemez sürüm olarak kullanmanın şu anki tek yolu bu. GITHUB_TOKEN için varsayılan izni depo içeriğinde yalnızca okumaya indirin, ihtiyacı olan işte tek tek yükseltin. Bulut erişimi için uzun ömürlü anahtar saklamak yerine OpenID Connect ile doğrudan doğrulanın. Buna bir madde daha ekleyin: çatallanmış depodan gelen katkı isteklerinde koşan iş akışlarına sır vermeyin. Konunun devamı koda gömülü sır yönetimi ve yazılım tedarik zinciri güvenliği yazılarımızda.

Yapay zekâ hattınızı test ediyor

2024 DORA raporunun bulgusu şu: yapay zekâ benimsemesinde %25'lik bir artış, teslim hızında yaklaşık %1,5 ve teslim kararlılığında %7,2 düşüşle ilişkili görünüyor. Sebep kodun kalitesinden çok hacmi. Üretim hızlanınca parti büyüyor, büyük parti ise zaten riskin kaynağı. 2025 raporunun çerçevesi bunu tamamlıyor, yapay zekâyı bir yükseltici olarak tanımlıyor: mevcut güçlü ve zayıf yanları büyütüyor. Hattınız on dakikada geri bildirim veriyorsa ve geri dönüş gerçekten çalışıyorsa, üretilen fazladan kod hızla değere dönüşür. Hattınız elle yürütülen bir yayın gecesinden ibaretse aynı araç sizi daha hızlı bozar.

Bu haftaya sığan ilk adım

Beş soruyu tek cümleyle cevaplamayı deneyin. Bir: son 30 günde kaç kez üretime çıktınız? İki: bir değişikliğin birleşmesinden yayına kadar geçen süre medyan olarak ne kadar? Üç: yayına çıkmak kaç elle adım gerektiriyor? Dört: son geri dönüş ne zaman denendi ve kaç dakika sürdü? Beş: hattın eriştiği sırlar hangileri, hangi üçüncü taraf eylemler sabitlenmemiş durumda?

En hızlı kazanç genelde üçüncü sorudan çıkar. Elle yapılan dağıtım adımlarını tek bir betiğe indirmek çoğu ekipte birkaç günlük iş ve hem teslim süresini hem de gece yapılan hataları aynı anda düşürür. Eski bir sistemi kademeli taşırken hattı neden ilk iş kurmak gerektiğini eski yazılımı yenileme yazımızda, aynı disiplinin entegrasyon uçlarında nasıl işlediğini veri senkronizasyonu yazımızda anlattık.