Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
CI, birbirinden uzun süre habersiz ilerleyen değişikliklerin büyük bir entegrasyon anında buluşması yerine uyumsuzlukların küçük kapsamda ve erken görülmesini hedefler.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Otomatik build ve testler mainline'ın bilinen durumunu görünür kılar. Pratik bütün hataları engellemez; geri bildirimi hızlandırır ve bozuk entegrasyona yanıt verme sorumluluğunu netleştirir.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-004 bağlamında junior'ın Pull Request'ında otomatik bir workflow başarısız görünür. Junior “CI bozuldu” demekle yetinmez ve yeşile dönmesi için testi silmez.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Hangi workflow, job ve step'in başarısız olduğunu; hangi commit için çalıştığını ve logdaki ilk anlamlı hatayı kontrol eder. Sorunu yerelde yeniden üretmeye çalışır, değişikliğin mi yoksa ortam veya güvenilmez testin mi etkili olduğunu kanıtla ayırır ve ekip akışına göre düzeltme ya da yardım ister. Bu pre-merge check yararlıdır; değişiklik mainline'a sık entegre edilmiyorsa tek başına CI pratiğinin tamamlandığını göstermez.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Kırmızı görünen şey CI kavramının kendisi değil, bu commit için çalışan test job'ı. Önce başarısız step'i ve logu doğrulayalım; sonra kod hatası mı, test güvenilirliği mi olduğunu ayıralım.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: CI, mainline, CI service, workflow/pipeline, build, job, step ve check ifadelerini birbirinden ayırır.
- Açıkla: Sık entegrasyon ile otomatik hızlı feedback'in birlikte neden CI pratiğini oluşturduğunu; tek başına araç hesabı veya pipeline dosyasının yeterli olmadığını anlatır.
- Uygula: Başarısız bir kontrolde commit, workflow/job/step ve log bağlamını belirler; kanıt olmadan testi kapatmaz; ekipte doğru yardım veya düzeltme yolunu seçer.
- Şimdilik bilmesi gerekmeyen: CI platformu seçmek, runner altyapısı yönetmek, pipeline mimarisi kurmak ve organizasyon çapında branch stratejisi tasarlamak.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Değişiklikler uzun süre ayrı kaldığında farklı varsayımlar ve uyumsuz kod daha geç karşılaşır; entegrasyon işi büyür ve hatanın kaynağını daraltmak zorlaşır.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
CI bu gecikmeyi azaltmak için entegrasyonu küçük ve sık bir ekip alışkanlığına, doğrulamayı ise tekrarlanabilir otomatik feedback'e dönüştürür. Bu pratik, belirli bir araç markasının ortaya çıkışından çok değişiklikleri erken buluşturma ihtiyacıyla ilgilidir.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler entegrasyon riskini küçük parçalara ayırmak, build/test sonucunu tekrarlanabilir kılmak ve ortak codebase'in durumunu görünür tutmak için CI uygulayabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
GitHub Actions, Jenkins veya başka servisler otomasyonu çalıştırabilir; mainline tanımı, pre-merge kontrolleri, hangi testlerin zorunlu olduğu ve kırık build'e yanıt biçimi ekibe göre değişir. Fowler ve DORA yaklaşımları bu pratiği açıklayan iki çerçevedir; belirli bir şirketin policy'si değildir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
CI otomasyon, güvenilir ve hızlı testler, küçük değişiklikler ve bozuk build'e erken yanıt disiplini gerektirir. Yavaş veya flaky kontroller feedback'e güveni azaltabilir; çok uzun yaşayan branch'ler ise otomasyon çalışsa bile gerçek entegrasyonu geciktirebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Fowler'ın mainline'a en az günlük entegrasyon tanımı ve DORA'nın trunk/small batch yaklaşımı güçlü bir çerçevedir; ekip bağlamı açıklanmadan belirli bir araç veya workflow zorunluluğuna dönüştürülmemelidir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Jenkins veya GitHub Actions kullanıyorsak CI yapıyoruz.” Eksik; araç otomasyonu çalıştırır, pratik sık entegrasyon ve hızlı yanıt davranışını da gerektirir.
- “CI ile Pipeline aynı şeydir.” Yanlış; pipeline/workflow otomatik süreç tanımıdır ve CI, deployment veya başka işler için kullanılabilir.
- “CI bir Build'dir.” Yanlış; build CI feedback döngüsünün bir parçasıdır.
- “Pull Request'taki testler geçiyorsa ekip kesin Continuous Integration uyguluyordur.” Yanlış; pre-merge test sık mainline entegrasyonunu tek başına kanıtlamaz.
- “CI başarılıysa kod production'a otomatik yayımlanmıştır.” Yanlış; CI, Continuous Delivery ve Continuous Deployment ayrı kavramlardır.
- “Kırmızı check her zaman son kod değişikliğinin hatalı olduğunu kanıtlar.” Yanlış; job, step, ortam ve test güvenilirliği incelenmelidir.
Gerilim ve çözüm1. bölüm
