🔗 CI/CD ve Otomasyon Entegrasyonu

CI/CD ve Otomasyon Entegrasyonu: Üretim bandındaki bir kalite sensörünü düşün: hatalı parçayı gördüğü anda otomatik olarak bir arıza fişi kesiyor ve bandı durduruyor.

Üretim bandındaki bir kalite sensörünü düşün: hatalı parçayı gördüğü anda otomatik olarak bir arıza fişi kesiyor ve bandı durduruyor. Kulağa mükemmel geliyor — ta ki sensör kalibrasyonu bozulup her parçaya fiş kesmeye başlayana kadar. O noktada operatörler fişlere bakmayı bırakır ve sistem hiç olmadığından daha kötü hâle gelir. Düşündürücü soru: koşum kırıldığında otomatik bug açmak niçin her zaman iyi bir fikir değildir? Çünkü otomatik açılan kayıtların çoğu yeni bilgi taşımaz: aynı flaky test her gece aynı ticket'ı doğurur ve gerçek bir hata bu gürültünün içinde kaybolur. Karşılaştır: koşum kırıldığında her seferinde e-posta gönderen bir CI kurulumu, birkaç hafta içinde kimsenin okumadığı bir klasöre dönüşür. Bildirim ne kadar ucuzsa o kadar değersizleşir; otomatik ticket için de aynı yasa geçerlidir. QA açısından doğru tasarım şudur: otomatik kayıt açmadan önce aynı imzayı taşıyan açık bir kayıt var mı diye ara; varsa yeni ticket açma, mevcut kaydın altına koşum numarasını ve rapor linkini yorum olarak ekle. Böylece bir hata bir kayıt olarak kalır ama kaç kez tekrarlandığı da ölçülebilir hâle gelir.

🧭 Bu Sekmede Ne Öğreneceksin

Commit mesajından issue'ya bağ kurmayı (smart commit); CI koşumu kırıldığında otomatik bug açma akışını ve tuzaklarını; tekrar eden ticket'ları önleyen arama-önce stratejisini; ortam bilgisinin ve koşum artefaktının (rapor linki, ekran görüntüsü, log) kayda nasıl iliştirileceğini işleyeceğiz.

🎬 Bir CI Koşumu Kırıldığında: Otomatik Bug mı, Gürültü mü?

Arama: Aynı İmza Var mı?

Gece 03:00 — CI koşumu ödeme akışı testini kırıyor. Kimse uyanık değil, ama sistemin bir kararı vermesi gerekiyor: yeni bir bug mı açsın, yoksa başka bir şey mi yapsın?

Adım 1 — Koşum kırılır. Naif bir tasarım burada doğrudan "bug aç" der — ama bu test her gece rastgele bir ağ gecikmesi yüzünden kırılıyorsa, bu YEDİNCİ aynı bug olur.

Adım 2 — Doğru tasarım önce ARAR: "aynı test adı + aynı hata imzasıyla açık bir bug var mı?" JQL sekmesinde öğrendiğin `summary ~ "..."` operatörü tam olarak burada işe yarar.

Adım 3a — Aynı imzalı açık bir bug BULUNURSA: yeni ticket açılmaz, mevcut kayda "koşum #4821, build 2026.8.3" bilgisiyle bir yorum eklenir. Bug hâlâ TEK kayıt, ama tekrar sayısı ölçülebilir.

Adım 3b — Aynı imzalı bug BULUNAMAZSA: yeni bir bug açılır, ortam bilgisi ve koşum raporunun linki otomatik eklenir. Bu, gerçekten YENİ bir hata olduğu için haklı bir kayıttır.

Final (kontrast) — Arama adımı ATLANSAYDI: her gece aynı flaky test için yeni bir ticket açılır, bir ay sonra otuz "tekil" bug birikir. Takım bu gürültüde gerçek bir hatayı kaçırır — üretim kalite sensörünün her parçaya fiş kesip operatörleri fişlere bakmaktan vazgeçirmesiyle AYNI mekanizma.

1️⃣ I1. Smart Commit: Commit Mesajından Issue'ya Bağ

Bir smart commit, git commit mesajının içine gömülen özel bir sözdizimidir — Jira bu mesajı ayrıştırıp issue üzerinde otomatik bir işlem yapar. Bu, Jira Nedir? sekmesinde gördüğün "commit mesajına anahtar koymak" fikrinin ötesine geçer: mesaj yalnızca bağlanmakla kalmaz, bir KOMUT da taşır.

`SHOP-142 #comment kupon hesaplaması düzeltildi #time 1h 30m` şeklinde bir commit mesajı yazıldı. Bu mesaj Jira'da NE yapar?