GitHub Actions pipeline'ı önbellek ve matrix ile nasıl hızlanır?

Pipeline neden yavaşlar?

Yavaş bir pipeline geliştiriciyi bekletir, geri bildirimi geciktirir ve zamanla insanları testleri atlamaya iter. Yavaşlığın tipik nedenleri bellidir: her çalıştırmada bağımlılıkların baştan indirilmesi, birbirinden bağımsız işlerin art arda koşması, gereksiz yere çalışan işler ve ağır, bölünmemiş test takımları.

Hızlandırmaya başlamadan önce ölçün. Çalıştırma ekranında hangi adımın en çok zaman aldığını bulun; çoğu pipeline'da süre birkaç adımda yoğunlaşır. Ölçmeden yapılan optimizasyon çoğu zaman en az kazanç getiren yere emek harcar. Başlıca araçlar, tekrarlanan işi önbelleğe almak ve bağımsız işi paralelleştirmektir.

Bağımlılık önbelleği nasıl çalışır?

Önbellek, bir çalıştırmada üretilen dosyaları (örneğin indirilen paketler) saklayıp sonraki çalıştırmalarda geri yükler. Her önbelleğin bir anahtarı (key) vardır. Anahtar tam eşleşirse önbellek geri yüklenir (isabet); eşleşmezse iş başarıyla bittiğinde yeni bir önbellek oluşturulur. Mevcut bir önbelleğin içeriği değiştirilemez; güncellemek için yeni anahtar kullanılır.

Anahtarı bağımlılık kilit dosyasına bağlamak yaygın pratiktir: hashFiles işlevi bir dosyanın özetini hesaplar, dosya değişince özet değişir ve yeni önbellek oluşur. Böylece bağımlılıklar değişmediği sürece önbellek yeniden kullanılır, değiştiğinde otomatik yenilenir. Anahtar; işletim sistemi, dil sürümü ve kilit dosyası özetini içerecek şekilde kurulursa farklı ortamların önbelleği karışmaz.

Pek çok paket yöneticisi (npm, Yarn, pnpm, pip, Poetry, Gradle, Maven, Go modülleri ve diğerleri) için ilgili setup action'ı önbelleği yerleşik olarak destekler. Uygun olduğunda elle önbellek yapılandırmak yerine bunu kullanmak daha az hata üretir.

restore-keys, kapsam ve temizlenme

Tam eşleşme yoksa restore-keys devreye girer: bunlar sırayla denenen yedek anahtarlardır ve ön ek eşleşmesiyle çalışır. Genel bir ön ek, benzer bir eski önbelleği yükleyerek tam bir indirmeden kurtarır; eksik olanlar sonra tamamlanır. Birden çok eşleşme varsa en yeni olan seçilir. Anahtarları en özelden en genele doğru sıralayın.

Kapsam kuralı önemlidir: bir çalıştırma önce kendi dalının önbelleklerine, sonra varsayılan dalınkilere bakar. Pull request çalıştırmaları taban dalın önbelleğinden de yararlanabilir. Kardeş veya alt dalların önbelleklerine erişilemez. Pull request ile oluşturulan önbellekler birleştirme referansına özeldir ve yalnızca o pull request'in yeniden çalıştırmalarında kullanılır. Bu yüzden ana daldaki bir çalıştırmanın önbelleği ısıtması, bütün dalların hızlanması için önemlidir.

Önbellekler süresiz durmaz: uzun süre erişilmeyenler silinir ve depo başına toplam bir depolama sınırı vardır; sınır dolunca en az erişilenler silinir. Sık silinme önbellek çalkantısına yol açar; bu durumda anahtar stratejisini ve önbelleğe alınan içeriği gözden geçirin. Güncel sınırlar için resmi dokümantasyona bakın.

Matrix stratejisi ile paralel çalıştırma

Aynı işi farklı kombinasyonlarda (işletim sistemi, dil sürümü, bileşen) çalıştırmak gerektiğinde her kombinasyon için ayrı iş yazmak yerine matrix stratejisi kullanılır. strategy.matrix altında değişkenler ve değer listeleri tanımlanır; iş her kombinasyon için ayrı koşar ve bu işler paralel yürür. Böylece tüm kombinasyonların testi, sırayla koşmaktan çok daha kısa sürede biter.

Matrix'i ayarlamak için araçlar vardır. include ile ek yapılandırma ekler ya da mevcut kombinasyonları genişletirsiniz; exclude ile anlamsız kombinasyonları çıkarırsınız. fail-fast açıkken bir iş başarısız olunca kuyruktaki ve süren matris işleri iptal edilir; tüm kombinasyonların sonucunu görmek istiyorsanız kapatın. max-parallel aynı anda çalışacak iş sayısını sınırlar, sınırlı çalıştırıcı kapasitesinde işe yarar. continue-on-error ise deneysel bir kombinasyonun başarısızlığının tümünü bozmasını engeller.

Matrix'in bedeli kapasitedir: kombinasyonlar arttıkça toplam çalışma süresi ve maliyet de artar. Yalnızca gerçekten desteklediğiniz kombinasyonları test edin.

Başka hızlandırma yolları

Önbellek ve matrix dışında etkili yöntemler şunlardır:

• Gereksiz çalıştırmayı kaldırmak: paths filtresiyle yalnızca ilgili dosyalar değişince çalışmak, dokümantasyon değişikliklerinde testi atlamak.
• Eşzamanlılık kontrolü: aynı dal için yeni bir çalıştırma başlayınca eskisini iptal etmek (concurrency).
• Bağımsız işleri paralel koşturmak: lint, birim test ve güvenlik taramasını ayrı işlere bölmek ve needs yalnızca gerçek bağımlılıkta kullanmak.
• Testleri bölmek: büyük test takımını parçalara ayırıp matrix ile paralel koşturmak.
• Docker imajı derlerken katman önbelleğinden yararlanmak ve çok katmanlı derleme kullanmak.
• Ağır ve nadir gereken adımları (tam entegrasyon testi, kapsamlı tarama) her gönderimde değil, birleştirme öncesinde ya da zamanlanmış çalıştırmada koşturmak.
• Gerektiğinde daha güçlü çalıştırıcı seçmek; yavaş makine bazen en ucuz çözümdür.

Örnek senaryo: yavaş bir test pipeline'ı

Örneğin bir web uygulamasının pipeline'ında her çalıştırma bağımlılıkları sıfırdan indiriyor, lint ve testler art arda koşuyor, ayrıca birkaç dil sürümünde test için aynı iş birkaç kez elle kopyalanmış. İlk adımda ölçüm yapılır ve en uzun sürenin bağımlılık kurulumu ile test takımı olduğu görülür.

Çözüm şu sırayla uygulanır: kurulum için setup action'ın yerleşik önbelleği açılır ve anahtar kilit dosyasına bağlanır; lint ile test ayrı işlere bölünür; sürüm kopyaları tek bir matrix işine dönüştürülür; dokümantasyon değişikliklerinde pipeline atlanır; aynı dal için eski çalıştırmalar iptal edilir. Her değişiklikten sonra süre yeniden ölçülür ve gerçekten fayda sağlamayan değişiklik geri alınır.

Bu örnek kurgusaldır; kazanç, projenin yapısına ve test takımının büyüklüğüne bağlıdır.

Sık yapılan hatalar

• Anahtara kilit dosyası özeti koymamak; bağımlılıklar değişse bile eski önbellek kullanılır ya da hiç isabet olmaz.
• Çok geniş içeriği (örneğin tüm çalışma dizinini) önbelleğe almak; depolama sınırını hızla doldurur ve eskileri siler.
• Önbelleğe gizli bilgi ya da kişisel veri koymak.
• Matrix kombinasyonlarını gereksiz büyütmek.
• fail-fast davranışını bilmeden kullanmak; tek başarısızlık yüzünden diğer kombinasyonların sonucu görünmez.
• Ölçmeden optimize etmek.
• Önbelleğin yalnızca ana daldan ısındığını unutup yeni dallarda yavaşlıktan şaşırmak.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

CI/CD Pipeline Tasarımı (GitHub Actions) eğitiminde Sürekli Entegrasyon Boru Hattı modülü önbellek ve matrix gibi hızlandırma tekniklerinin doğal yeridir; Gözlemlenebilirlik ve Optimizasyon modülü ise pipeline süresinin ölçülmesi ve iyileştirilmesiyle ilgilidir. GitHub Actions Temelleri modülü workflow yapısını, Konteyner ve Image Yönetimi modülü imaj katman önbelleğini tamamlar.

Eğitim yazılım geliştiriciler, DevOps ve platform mühendisleri için uygundur. Pipeline süresi ve çalıştırıcı maliyeti birçok ekibi etkileyen kurumlarda, ortak optimizasyon pratikleri oluşturmak isteyen platform ekipleri için bir başlangıç noktası olabilir.