CI Pipeline — Geri Bildirim Neden Bu Kadar Geç Geliyor?
Önce şunu oku: Docker Katman Cache ve İmaj Boyutu
30 saniyede özet
Yavaş bir pipeline çoğu zaman aynı işi her koşuda baştan yapar ve birbirini beklemesi gerekmeyen aşamaları sıraya dizer. Cache tekrarı keser, paralel aşamalar bekleyişi kısaltır, hızlı testler kötü haberi erkene çeker.
Çamaşır gününü düşün. Yıkamak, kurutmak, ütülemek ve katlamak tek tek yapılırsa bütün gün sürer. Üstelik dolaptaki temiz gömlekleri de yeniden yıkıyorsan gün hiç bitmez.
-
Bayt: Ödeme servisine tek satırlık bir düzeltme yaptım. Pipeline başladı!
-
Sen: Yirmi dakika sonra kırmızı geldi. Hata ilk birim testindeymiş.
-
Bayt: O test birkaç saniyede koşuyor. Neden yirmi dakika bekledik?
-
Bayt: Testten önce bir sürü iş yapılıyor olmalı. Pipeline'ın içine bakalım.
Süre nereye gidiyor?
Bir CI pipelineHer commit'te kodu derleyip testleri otomatik koşan aşamalar dizisi. Asıl işi, değişikliğin sağlam olup olmadığını geliştiriciye hızlıca söylemektir.Sözlükte gör →’ı her commit’te kodu çeker, bağımlılıkları kurar, derler, testleri koşar ve bir imaj üretir. Sırayla koşan aşamaların süreleri toplanır.
Bu sürenin büyük bir kısmı çoğu zaman tekrarlanan iştir. Bağımlılıklar bir önceki koşudan beri değişmemiştir, ama her seferinde baştan indirilir.
Kafam karıştı, daha basit anlat
Sırayla koşan aşamaların süresi toplanır. Bir kısmı her seferinde aynı işi yapar.
Bir CI pipeline'ı her commit'te ne yapar?
Sırayla koşan aşamalardan oluşan bir pipeline'ın toplam süresi nedir?
Tekrarı kes, bekleyişi kısalt
Birim testleri, entegrasyon testleri ve Docker imajı derlemeden sonra yan yana koşarsa, bu üç aşamanın toplam süresini ne belirler? Cevabı göster
En uzun olanı. Yan yana koşan aşamalar birbirini beklemez. Üçü 3, 8 ve 4 dakika sürüyorsa, hepsi 8 dakikada biter.
Adım adım oku
- Her şey sırayla: bütün gün sürer.
- Temiz olanı yeniden yıkama: cache.
- Birbirini beklemeyen makineler yan yana.
- Tekrarlananı kes, bağımsızı paralel koştur.
Cache, bir önceki koşunun sonucunu bir cache anahtarıBir cache kaydının neye bağlı olduğunu söyleyen anahtar; genellikle bağımlılık dosyasının özeti. Dosya değişince anahtar da değişir ve eski cache kullanılmaz.Sözlükte gör → ile saklar. Anahtar genellikle bağımlılık dosyasının özetidir; dosya değişmediyse bağımlılıklar indirilmez, cache’ten gelir.
Paralellik ise bekleyişi kısaltır. Birim testleri ile imaj derlemesi birbirinin sonucuna ihtiyaç duymaz; yan yana koşarlar ve toplam süre en uzun aşama kadar olur.
Kafam karıştı, daha basit anlat
Cache tekrarlanan işi keser. Paralel aşamalarda süreyi en uzun aşama belirler.
Birim testleri 3, entegrasyon testleri 8, imaj 4 dakika sürüyor ve üçü yan yana koşuyor. Bu bölüm ne kadar sürer?
Bağımlılık cache'inin anahtarı neden pom.xml ya da lock dosyasının özetinden üretilir?
Kendin gör
Commit’ten yeşil ışığa
Tohum 586559- Kodu çek0–0,5 dk, bitti
- Bağımlılıklar0,5–6,5 dk, bitti
- Derle6,5–8,5 dk, bitti
- Birim testleri8,5–11,5 dk, bitti
- Entegrasyon testleri11,5–19,5 dk, bitti
- Docker imajı19,5–23,5 dk, bitti
- Staging’e deploy23,5–24,5 dk, bitti
Geçen süre: 0 dk
Şu an ne oldu?
Pipeline: cache yok · sıralı
Geliştirici commit’i gönderdi. Sonucu ne zaman öğrenecek?
Görevler0/3
Yeşil ışığı 24 dakikadan uzun bekleaçık
İpucu
Varsayılan ayarlar yeter.
Yeşil ışığı 12 dakikada alaçık
İpucu
İki iyileştirme birlikte.
Kırık testi 6 dakikada öğrenaçık
İpucu
Testlere varmadan önceki bekleme kısalmalı.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Cache yok, her şey sırayla: yeşil ışık 24,5 dakika sonra geldi.
- Cache’i aç. Bağımlılıklar ve imaj katmanları cache’ten geldi: 16 dakika.
- Cache’i kapat, paralel aç. Testler ve imaj yan yana koştu: 17,5 dakika.
- İkisini birlikte aç. 12 dakika; süreyi artık en uzun aşama, entegrasyon testleri belirliyor.
- Cache’i kapat, paraleli kapat ve “Bir birim testi kırık”ı aç. Kırmızı haber 11,5 dakika sonra geldi. Cache’i açınca 6 dakikaya indi.
Cache'i açmak kırık bir birim testinin ne zaman öğrenildiğini nasıl etkiler?
Paralel koşuda birim testi kırmızı oldu; entegrasyon testleri hâlâ koşuyor. Ne yapılmalı?
Tuzaklar
Yanlış cache anahtarı. Anahtar bağımlılık dosyasını içermezse, yeni bir kütüphane eklediğinde eski cache kullanılır. Anahtarı lock ya da pom dosyasının özetinden üret.
Yavaş testleri öne koymak. Entegrasyon testleri birim testlerinden önce koşarsa, saniyelerde bulunabilecek bir hata dakikalar sonra görünür. Hızlı ve sık kırılan testler önce koşmalı.
Eski koşuları beklemek. Aynı dala art arda üç commit gelirse, ilk ikisinin pipeline’ı artık kimseyi ilgilendirmez. Bir dalda yeni koşu başlayınca eskisini iptal et.
Kafam karıştı, daha basit anlat
Cache anahtarını doğru kur, hızlı testleri öne al, eski koşuları iptal et.
Aynı dala art arda üç commit geldi. İlk iki commit'in pipeline'ları için ne yapılmalı?
Aşağıdaki örnek bir ödeme servisinin GitHub Actions pipeline’ından: Maven cache’i, paralel işler, imaj katmanları için cache ve aynı daldaki eski koşuların iptali.
Derinleş · Ödeme servisi pipeline'ı: cache, paralel işler, önce hızlı testler 3 dosya · ~110 satır · ilk okumada atlayabilirsin
Kendini sına
Paralel koşan aşamaların toplam süresini en uzun olanı belirler.
Cache anahtarı bağımlılık dosyasını içermiyor. Yeni bir kütüphane eklendi. Ne olur?
Aklında kalacak üç şey
- 1 Pipeline'daki en büyük israf çoğu zaman tekrarlanan iştir: her koşuda aynı bağımlılıkları indirmek ve aynı imaj katmanlarını kurmak. Cache bunu bir önceki koşudan getirir.
- 2 Birbirinin sonucuna ihtiyaç duymayan aşamalar yan yana koşabilir. O zaman toplam süreyi bütün aşamaların toplamı değil, en uzun olanı belirler.
- 3 Bir pipeline'ın asıl işi geliştiriciye haber vermektir. Hızlı ve sık kırılan testler öne alınırsa kötü haber, uzun aşamalar başlamadan gelir.
4 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.