CI/CD Kalite Kontrolleri: Her Yeşil Build Yayına Hazır mı?

Build başarısını ürün kabulünden ayırın

Derleme, bağımlılık çözümü ve paketleme teknik başlangıç kontrolleridir. Birim testleri küçük davranışları, entegrasyon testleri bileşen ilişkilerini, kabul testleri kullanıcı işini değerlendirebilir. Hangi testin neyi kapsadığını yazın; tek bir “tests passed” satırı bütün kaliteyi temsil etmez.

Google SRE sürüm mühendisliği yaklaşımı, tekrarlanabilir ve kontrollü yayın süreçlerinin önemini ele alır. [2] Kullanılan sürümün hangi kaynak kodu ve girdilerden üretildiği bilinmelidir. Test edilmiş paket yerine son anda yeniden oluşturulan farklı çıktıyı yayına almak karşılaştırmayı zayıflatabilir.

Kontrolleri risk ve hız dengesine göre sırala

Hızlı biçim ve temel testler erken çalışabilir. Daha uzun entegrasyon ve performans kontrolleri ilgili değişikliklerde yürütülebilir. Her küçük metin değişikliğinde bütün ağır testleri çalıştırmak zorunlu olmayabilir, ancak kritik kodun kontrolsüz geçmesine de izin verilmemelidir.

Bir kontrolün başarısızlığını görmezden gelmek kolay olmamalıdır. İstisna gerekiyorsa yetkili kişi, gerekçe ve risk kaydı bulunsun. Sürekli rastgele başarısız olan testler düzeltilmelidir; herkese “yeniden çalıştırınca geçer” alışkanlığı kazandırmak kalite kapısının anlamını azaltır.

Örnek: fiyat hesabı değişen e-ticaret sürümü

Varsayımsal sürümde kampanya önceliği değişiyor. Derleme ve arayüz testleri geçebilir, fakat kısmi iade hesabı yanlış olabilir. Değişiklik kapsamına göre fiyat, sipariş ve iade senaryoları birlikte test edilmelidir. Sadece kodun çalışması ticari doğruluğu göstermez.

Tablodaki kontroller önerilen kapsam örneğidir. Ürünün risklerine göre güvenlik, erişilebilirlik veya yük testleri de eklenebilir.

Ortam ve yetkileri yayın hattına göre ayırın

Test işi gereksiz üretim yetkisine sahip olmamalıdır. Dağıtım bilgileri ve gizli anahtarlar günlüklerde görünmemelidir. Hangi adımın hangi ortama erişebildiği açık olsun. Önizleme ortamı gerçek müşterilere bildirim göndermemelidir.

GitHub dağıtım inceleme dokümantasyonu ortam onaylarının nasıl kullanılabildiğini açıklar; kullanılabilirlik hesap ve depo koşullarına bağlı olabilir. [1] Bir onay düğmesinin varlığı yeterli değildir. Onaylayan kişinin hangi test ve değişiklik kanıtını gördüğü belirlenmelidir.

Veri geçişini dağıtımın görünmeyen eki yapmayın

Yeni uygulama şema değişikliği gerektiriyorsa sıralama ve geri dönüş planı yazılmalıdır. Kod geri alınabildiği halde veri geri alınamayabilir. CI/CD hattının migration durumunu ve hatasını açıkça göstermesi gerekir. Geçiş başarısızken uygulamayı kısmen açık bırakma davranışı test edilmelidir.

Aynı anda iki dağıtım başlatıldığında hangi sürümün geçerli olacağı da belirlenmelidir. Uzun süren eski işin daha yeni sürümün üstüne yazması engellenmelidir. Ortam kilidi, sıra veya iptal politikası kullanılan altyapıya göre seçilebilir.

Canlı kontrol ve geri dönüşü tamamlayın

Dağıtım servisi başarılı dediğinde kritik URL ve kullanıcı akışı ayrıca kontrol edilmelidir. Sağlık uç noktası sadece süreç yaşadığını gösterebilir; gerekli veri ve bağımlılıklar çalışmıyor olabilir. Kontrolün kapsamı müşteri etkisine göre belirlenmelidir.

Teslimde pipeline tanımı, test kapsamı, istisna politikası, dağıtılan sürüm kimliği ve geri dönüş provası bulunsun. Yayın sonrası izleme sorumlusu belli olsun. Otomasyonun amacı insan kontrolünü körleştirmek değil, kararın kanıtını tekrar üretilebilir hale getirmektir.

Sık sorulan sorular

### Bütün testler geçiyorsa hata çıkmaz mı? Böyle bir garanti yoktur. Testler tanımlanan kapsamı kontrol eder; üretim koşulları ve yeni veri farklı sorunlar yaratabilir. İzleme ve geri dönüş yine gereklidir.

Manuel yayın onayı otomasyonla çelişir mi?

Hayır. Riskli adımlarda kanıta dayalı onay süreçte yer alabilir. Önemli olan onayın açık koşullara ve yetkiye dayanmasıdır.