CI/CD'de Build Cache Yönetimi: 3 Pratik Yaklaşım

Giriş: Build Süreleri ve Cache’in Önemi

CI/CD pipeline’larınızda karşılaştığınız yavaş build süreleri, geliştirici verimliliğini düşüren ve projelerinizi riske atan ciddi bir sorun olabilir. Her build işleminin sıfırdan başlaması, özellikle büyük projelerde saatler sürebilir. Bu durum, tekrarlanan ve zaman alıcı indirmeler, derlemeler ve testler nedeniyle hem geliştiricilerin bekleme süresini artırır hem de CI/CD altyapısının maliyetlerini yükseltir. İşte tam bu noktada build cache yönetimi devreye giriyor.

Cache, daha önce yapılan işlemlerin sonuçlarını saklayarak, aynı veya benzer işlemler tekrar istendiğinde bu sonuçları yeniden kullanmamızı sağlar. CI/CD bağlamında build cache, bağımlılıkları, derlenmiş kodları veya test sonuçlarını saklayarak bir sonraki build’in çok daha hızlı tamamlanmasına yardımcı olur. Bu, sadece zaman kazandırmakla kalmaz, aynı zamanda maliyetleri de düşürür. Kendi projelerimde, doğru build cache stratejileriyle build sürelerini belirgin ölçüde azalttığımı gördüm. Bu yazıda, CI/CD pipeline’larınızda build sürelerini kısaltmak için kullanabileceğiniz 3 pratik build cache yönetim yaklaşımını derinlemesine inceleyeceğiz.

1. Bağımlılıkları (Dependencies) Cache’leme

CI/CD pipeline’larının en çok zaman alan kısımlarından biri, projenin ihtiyaç duyduğu tüm harici kütüphaneleri ve paketleri indirmektir. Özellikle büyük projelerde veya sık güncellenen bağımlılıklara sahip projelerde bu indirme işlemleri ciddi zaman kaybına yol açabilir. Build cache’in en temel ve etkili kullanımlarından biri, bu bağımlılıkları cache’lemektir.

Birçok paket yöneticisi (npm, yarn, pip, Maven, Gradle vb.) kendi lokal cache mekanizmalarına sahiptir. CI/CD ortamında ise bu lokal cache’lerin kalıcı hale getirilmesi gerekir. Örneğin, bir Node.js projesinde node_modules klasörünü veya bir Python projesinde .venv veya ~/.cache/pip dizinini cache’lemek, bir sonraki build’de bu dosyaların tekrar indirilmesini engeller. Bu yaklaşımı uygularken dikkat edilmesi gereken en önemli nokta, cache’in tutarlılığını sağlamaktır. Eğer package.json veya requirements.txt gibi bağımlılık dosyaları değişirse, eski cache’in geçersiz kılınması ve yeni bağımlılıkların indirilmesi gerekir.

# Örnek: npm ile bağımlılıkları cache'leme (GitLab CI/CD)

cache:
  key: ${CI_COMMIT_REF_SLUG}-npm-${CI_PROJECT_DIR}
  paths:
    - node_modules/
  policy: pull-push

build_job:
  script:
    - npm ci # npm ci, package-lock.json'a göre kurulum yapar ve cache için daha uygundur
    - npm run build

Yukarıdaki GitLab CI/CD örneğinde, node_modules klasörü cache’leniyor. key alanı, branch’e ve proje dizinine göre benzersiz bir cache anahtarı oluşturarak farklı branch’ler için ayrı cache’ler kullanılmasını sağlar. policy: pull-push ise job başladığında cache’i indirip, job bittiğinde güncellenmiş cache’i sunucuya geri yükler. Bu yöntem, ilk build’den sonraki tüm build’lerde bağımlılık indirme süresini neredeyse sıfıra indirir. Ancak, bağımlılık dosyasında yapılan her değişiklikte cache’in yenilenmesi gerektiğini unutmamak önemlidir.

2. Derlenmiş Kod (Compiled Code) Cache’leme

Özellikle statik tipli dillerle (Java, C#, Go, Rust) veya karmaşık derleme süreçleri olan dillerle (C++, TypeScript) çalışırken, kodun derlenme aşaması da ciddi zaman alabilir. Bu derleme sonuçlarını da cache’lemek, build sürelerini önemli ölçüde kısaltabilir. Birçok derleyici ve build aracı, ara build çıktılarını (intermediate build artifacts) saklama yeteneğine sahiptir.

Örneğin, Gradle kullanan bir Java projesinde, Gradle’ın dahili cache mekanizması sayesinde daha önce derlenmiş sınıflar ve kaynak dosyaları saklanabilir. Benzer şekilde, TypeScript projelerinde tsc’nin --build veya --incremental modları ile yapılan derlemeler de cache’ten faydalanır. Bu derlenmiş kod cache’lerini CI/CD ortamında kalıcı hale getirmek, bağımlılık cache’lemeye benzer şekilde yönetilir.

# Örnek: Gradle build cache'ini CI/CD'de kullanma (Jenkins)
# Jenkinsfile snippet

pipeline {
    agent any
    options {
        // Build cache'i kalıcı hale getirmek için workspace'i koru
        keepWorkspaces()
    }
    stages {
        stage('Build') {
            steps {
                sh './gradlew build' // Gradle, build cache'ini otomatik olarak kullanır
            }
        }
    }
}

Jenkins gibi CI/CD araçlarında keepWorkspaces() seçeneği, job tamamlandıktan sonra workspace’in silinmesini engelleyerek Gradle’ın build cache’inin bir sonraki job’a aktarılmasını sağlar. Ancak, burada da dikkatli olmak gerekir. Eğer kaynak kodda yapılan bir değişiklik, derlenmiş kodun geçersiz olmasına neden oluyorsa, bu eski cache’in kullanılmaması gerekir. Build araçlarının sağladığı incremental build özellikleri bu tutarlılığı sağlamada yardımcı olur.

3. Artımlı Test (Incremental Testing) ve Test Sonuçları Cache’leme

Yazılım geliştirme süreçlerinde testler, kalitenin temel taşıdır. Ancak, binlerce test içeren bir projede tüm testleri her build’de çalıştırmak da önemli bir zaman dilimi alabilir. Bu sorunu çözmek için artımlı test ve test sonuçlarını cache’leme yaklaşımları devreye girer.

Artımlı test, sadece değişen kodla ilişkili testleri çalıştırma prensibine dayanır. Birçok test framework’ü (örneğin, Jest, Pytest) bu yeteneği destekler. Değişen dosyaları analiz ederek, yalnızca bu dosyalara dokunan testleri çalıştırır. Bu, tüm test setini çalıştırmaktan çok daha hızlıdır. Test sonuçlarını cache’lemek ise, eğer testler üzerinde hiçbir değişiklik yapılmadıysa, önceki test çalıştırmasının sonuçlarını yeniden kullanarak o testleri atlamak anlamına gelir.

# Örnek: Jest ile artımlı test (Nx Monorepo)
# package.json snippet

"scripts": {
  "test:e2e": "jest apps/my-app/e2e/ --ci --changedSince=main",
  "test:unit": "jest --changedSince=main",
  "test:all": "jest"
}

Nx gibi monorepo araçları, changedSince gibi parametrelerle hangi testlerin çalıştırılacağını belirlemekte yardımcı olur. Bu, özellikle büyük monorepolarda build sürelerini dramatik şekilde azaltır. Test sonuçlarını cache’lemek için ise CI/CD araçlarının cache mekanizmalarını kullanabiliriz. Örneğin, bir önceki build’de çalıştırılan testlerin sonuçlarını bir dosyaya kaydedip, sonraki build’de bu dosyayı kullanarak testleri atlayabiliriz.

Build Cache Yönetimi İçin Genel Yaklaşımlar

Yukarıda bahsettiğimiz üç ana yaklaşımın yanı sıra, build cache yönetimini daha etkili hale getirecek bazı genel stratejiler de bulunmaktadır. Bu stratejiler, hem bağımlılıkları, hem derlenmiş kodları hem de test sonuçlarını kapsayan bütüncül bir yaklaşım sunar.

Öncelikle, cache’in ne zaman geçersiz kılınması gerektiğini iyi anlamak gerekir. Bağımlılık dosyaları değiştiğinde, kaynak kodda yapılan değişiklikler derlenmiş kodları etkilediğinde veya test senaryoları güncellendiğinde cache’in yenilenmesi zorunludur. CI/CD araçlarının sunduğu cache anahtarı mekanizmalarını doğru kullanmak, bu geçersiz kılma işlemini otomatikleştirir. Örneğin, package-lock.json’ın hash’ini cache anahtarına dahil etmek, bu dosyadaki herhangi bir değişiklikte yeni bir cache oluşturulmasını sağlar.

İkinci olarak, dağıtık (distributed) cache çözümleri kullanmayı düşünebiliriz. Tek bir CI runner’ına bağımlı kalmak yerine, merkezi bir cache sunucusu (örneğin, Redis, S3 bucket) kullanmak, birden fazla CI agent’ının aynı cache’i paylaşmasını sağlar. Bu, özellikle büyük ekiplerde ve paralel çalışan CI/CD pipeline’larında performansı artırır. Cloud sağlayıcılarının sunduğu nesne depolama servisleri (AWS S3, Google Cloud Storage) bu amaçla sıklıkla kullanılır.

Üçüncü olarak, cache’in boyutunu ve süresini optimize etmek önemlidir. Aşırı büyük veya uzun süre saklanan cache’ler, disk alanı sorunlarına yol açabilir ve hatta zamanla bozulabilir. Belirli bir süre sonra otomatik olarak temizlenen veya belirli bir boyutu aşan cache’lerin kırpıldığı mekanizmalar kurmak, yönetimi kolaylaştırır.

# Örnek: S3 üzerinde dağıtık build cache (GitHub Actions)
# .github/workflows/build.yml snippet

- name: Cache node_modules
  uses: actions/cache@v3
  with:
    path: '**/node_modules'
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Bu GitHub Actions örneğinde, actions/cache action’ı S3 veya benzeri bir depolama alanını kullanarak node_modules klasörünü cache’liyor. key ve restore-keys stratejisi, bağımlılık değişikliklerine göre cache’in akıllıca yönetilmesini sağlar.

Sonuç: Daha Hızlı CI/CD, Daha Mutlu Geliştiriciler

CI/CD pipeline’larında build cache yönetimini doğru uygulamak, sadece teknik bir optimizasyon değil, aynı zamanda geliştirici deneyimini ve proje teslim hızını doğrudan etkileyen kritik bir faktördür. Bağımlılıkları, derlenmiş kodları ve test sonuçlarını akıllıca cache’leyerek, build sürelerini önemli ölçüde kısaltabilir, CI/CD altyapı maliyetlerini düşürebilir ve en önemlisi geliştiricilerin daha hızlı geri bildirim almasını sağlayarak verimliliği artırabilirsiniz.

Unutmayın ki, en iyi cache stratejisi, projenizin özel gereksinimlerine, kullandığınız teknoloji yığınına ve CI/CD ortamınıza bağlıdır. Bu yazıda sunduğum üç temel yaklaşım ve genel stratejiler, kendi pipeline’larınız için sağlam bir başlangıç noktası oluşturacaktır. Farklı cache anahtarı stratejilerini denemek, dağıtık cache çözümlerini araştırmak ve periyodik olarak cache temizliği yapmak, uzun vadede en iyi sonuçları almanızı sağlayacaktır. Build sürelerinizi azaltmak, daha çevik ve verimli bir geliştirme süreci için atılacak en önemli adımlardan biridir.