DevOps ve Yazılım Kalitesi

CI/CD Hattı: Acente Yazılımında Bir Değişiklik Yayına Nasıl Ulaşır?

InsureHub Ekibi
19 Ağustos 2026

Acente panelinde bir ekranın sabah farklı göründüğünü fark ettiğinizde, arka planda aslında uzun bir yolculuk tamamlanmıştır. Bir geliştiricinin yazdığı birkaç satır kod; derlenmiş, test edilmiş, gözden geçirilmiş ve kontrollü biçimde canlı ortama taşınmıştır. Bu yolculuğun otomatikleştirilmiş hâline CI/CD hattı denir. Sigorta acentelerine yazılım sağlayan bir ekip olarak InsureHub tarafında bu hattı, acentenin günlük işini kesintiye uğratmadan yazılımı geliştirebilmenin temel koşulu olarak görüyoruz.

Bu yazıda CI/CD kavramını teknik jargona boğmadan, bir değişikliğin hangi duraklardan geçtiğini ve her durağın acente kullanıcısı için neden önemli olduğunu adım adım anlatıyoruz.

CI ve CD ne anlama gelir?

Sürekli entegrasyon (CI), geliştiricilerin yaptığı değişikliklerin sık aralıklarla ortak kod tabanına birleştirilmesi ve her birleştirmede otomatik kontrollerin çalışmasıdır. Amaç, sorunları değişiklik küçükken ve bağlamı tazeyken yakalamaktır.

Sürekli teslimat ya da sürekli dağıtım (CD) ise kontrollerden geçen değişikliğin yayına hazır bir paket hâline getirilmesi ve tanımlı kurallarla canlı ortama taşınmasıdır. Teslimatta son adım bir onayla tetiklenir; dağıtımda ise tüm kontroller geçtiğinde süreç kendiliğinden ilerler. Hangisinin seçileceği, değişikliğin risk düzeyine ve ekibin olgunluğuna bağlıdır.

Bir değişikliğin yolculuğu: altı durak

  1. Dal ve birleştirme isteği: Geliştirici değişikliği ayrı bir dalda yapar ve ana koda birleştirme isteği açar. Bu istek, değişikliğin neden yapıldığını ve neyi etkilediğini anlatan bir kayıt hâline gelir.
  2. Derleme: Kod, bağımlılıklarıyla birlikte temiz bir ortamda derlenir. "Benim bilgisayarımda çalışıyordu" sorunu bu aşamada büyük ölçüde ortadan kalkar.
  3. Otomatik testler: Birim testleri, entegrasyon testleri ve seçili uçtan uca senaryolar çalışır. Herhangi biri başarısız olursa hat durur ve değişiklik ilerlemez.
  4. Kalite ve güvenlik kontrolleri: Statik analiz, kod stili denetimi ve bilinen açıklara sahip bağımlılık taraması yapılır.
  5. Hazırlık ortamı: Paket, canlıya benzeyen ama gerçek müşteri verisi içermeyen bir ortama kurulur. Burada ekip ve gerekirse ürün sorumlusu değişikliği gözle doğrular.
  6. Canlı ortam: Onaylanan paket, kademeli ya da tek adımda yayına alınır ve yayın sonrası izleme başlar.

Her durak acente için ne ifade eder?

Derleme ve test: sürprizlerin erken yakalanması

Bir acente kullanıcısı için en can sıkıcı durum, dün sorunsuz çalışan bir ekranın bugün hata vermesidir. Otomatik testler, mevcut davranışın bozulmadığını her değişiklikte yeniden kontrol eder. Özellikle teklif ekranları gibi birçok parçanın bir araya geldiği yerlerde, küçük bir değişikliğin beklenmedik bir yan etkisi bu aşamada ortaya çıkar.

Hazırlık ortamı: gerçeğe yakın prova

Hazırlık ortamı, değişikliğin canlıdaki koşullara benzer bir yerde denendiği prova sahnesidir. Trafik, kasko ve DASK sorgu akışları birbirinden farklı bilgiler ve adımlar içerdiği için, bu akışların her biri burada kendi senaryosuyla ayrı ayrı denenir. Böylece bir branştaki düzenlemenin diğer branşın akışını etkileyip etkilemediği canlıya çıkmadan görülür.

Canlı ortam ve geri alma

İyi kurulmuş bir hattın en değerli özelliklerinden biri, geri almanın da otomatik olmasıdır. Yayın sonrasında beklenmeyen bir davranış görülürse önceki sürüme dönüş, uzun bir manuel işlem yerine tanımlı bir adımla yapılabilir. Bu da acentenin acente yazılımını kullanırken yaşayabileceği aksaklığın süresini kısaltır.

Sık yapılan hatalar

  • Testleri atlanabilir bırakmak: Acil durumlar bahanesiyle testlerin devre dışı bırakılması, hattın güvencesini zamanla anlamsız hâle getirir.
  • Hazırlık ortamını ihmal etmek: Canlıdan çok farklı yapılandırılmış bir hazırlık ortamı, yanlış bir güven duygusu yaratır.
  • Büyük değişiklikleri biriktirmek: Hat ne kadar iyi olursa olsun, yüzlerce değişikliği tek seferde taşımak hata ayıklamayı zorlaştırır.
  • Yayın sonrası izlemeyi unutmak: Dağıtım tamamlandığında iş bitmez; ilk saatlerde hata oranları ve yanıt süreleri yakından izlenmelidir.

Web paneli ve mobil uygulama için ayrı hatlar

Web paneline yapılan bir değişiklik dakikalar içinde tüm kullanıcılara ulaşabilir. Mobil uygulamada ise mağaza incelemesi ve kullanıcının güncellemeyi yüklemesi gibi ek adımlar vardır. Bu nedenle mobil tarafta CI/CD hattı genellikle imzalı paket üretimi, test dağıtımı ve mağazaya gönderim gibi farklı duraklar içerir. İki hattın ortak noktası, aynı arka uç servisleriyle uyumlu kalmalarının test edilmesidir.

Acente olarak hangi soruları sorabilirsiniz?

Bir yazılım sağlayıcısını değerlendirirken CI/CD hattının ayrıntılarını bilmeniz gerekmez; ancak birkaç soru yazılımın nasıl yönetildiği hakkında iyi bir fikir verir:

  • Değişiklikler canlıya çıkmadan önce hangi otomatik kontrollerden geçiyor?
  • Bir sorun çıktığında önceki sürüme dönüş nasıl yapılıyor?
  • Yayınlar mesai saatlerinin yoğun dönemlerinden kaçınacak şekilde planlanıyor mu?
  • Kullanıcılar önemli değişikliklerden önceden haberdar ediliyor mu?

Bu soruların yanıtları, yazılımın uzun vadede ne kadar istikrarlı gelişeceğine dair somut ipuçları sunar. Kendi iş akışınız üzerinde nasıl çalıştığını görmek isterseniz bir demo talebi oluşturarak süreci yakından inceleyebilirsiniz.

Hattın sağlığını nasıl ölçeriz?

Bir CI/CD hattının iyi çalışıp çalışmadığını sezgiyle değil, birkaç basit göstergeyle değerlendirmek mümkündür. Yazılım sektöründe yaygın olarak kullanılan dört gösterge şunlardır:

  • Dağıtım sıklığı: Değişiklikler ne sıklıkla canlıya ulaşıyor? Sık ve küçük dağıtımlar, genellikle daha düşük risk anlamına gelir.
  • Değişiklik teslim süresi: Bir değişikliğin birleştirilmesinden canlıda çalışmasına kadar geçen süre. Bu süre uzadıkça değişiklikler birikir.
  • Değişiklik kaynaklı hata oranı: Yayınların ne kadarı geri alma ya da acil düzeltme gerektiriyor?
  • Toparlanma süresi: Bir sorun yaşandığında hizmetin normale dönmesi ne kadar sürüyor?

Bu göstergeler birbirini dengeler. Yalnızca hızı artırmaya odaklanan bir ekip hata oranını yükseltebilir; yalnızca hatayı azaltmaya çalışan bir ekip ise değişiklikleri biriktirip teslim süresini uzatabilir. Hepsine birlikte bakmak, hattın gerçek olgunluğunu gösterir.

Bu göstergeleri izlerken amaç ekipleri birbiriyle kıyaslamak değil, hattın zaman içindeki eğilimini görmektir. Örneğin hazırlık ortamındaki bekleme süresinin uzadığı fark edilirse, buradaki manuel adımların otomatikleştirilmesi öncelik kazanır. Acente kullanıcısı bu iyileştirmeleri doğrudan görmez; ancak taleplerinin daha kısa sürede ve daha az sürprizle karşılanmasında hisseder.

Sonuç

CI/CD hattı, acente kullanıcısının doğrudan görmediği ama her gün etkisini hissettiği bir altyapıdır. Değişikliklerin küçük, test edilmiş ve geri alınabilir biçimde yayına çıkması; yazılımın gelişirken istikrarını korumasını sağlar. Acente tarafında bunun karşılığı, ekranların öngörülebilir davranması ve yeniliklerin günlük işi aksatmadan gelmesidir.