JavaScript monorepo git boyutunu %94 nasıl küçülttük

 (jonathancreamer.com)
7 puan yazan GN⁺ 2024-10-28 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft’un büyük ölçekli JavaScript monoreposu 1JS, çok büyük miktarda kod ve katkı içeriyor. Yakın zamanda klonlanan repo 178GB’a ulaşmıştı.
  • Repo boyutu o kadar büyümüştü ki Avrupa’daki bazı kullanıcılar klonlayamıyordu.

Ders #1

  • Birkaç yıl önce repoya katıldığımda, reponun hızla büyüdüğünü fark ettim. İlk klonladığımda 1–2GB civarındaydı, ancak birkaç ay sonra zaten 4GB’a ulaşmıştı.
  • Büyük blob’ları tespit etmek için git-sizer aracını kullandık; bunlar genelde binary dosyalar yanlışlıkla check-in edildiğinde oluşuyor. Bunu önlemek için Azure DevOps’un check-in boyutu sınırlandırma özelliği kullanılabilir.
  • Beachball değişiklik dosyalarını silmediğimiz için sorun yaşandı. Bu sistem, Changesets’e benzer şekilde paketlerin semver aralıklarını otomatik olarak artırmak için kullanılıyor.
  • Tek bir klasörde binlerce dosya tutmama dersini çıkardık. Bunu çözmek için Beachball’a birden fazla değişikliği tek dosyada işleyecek bir pull request gönderdik ve değişiklik klasörünü periyodik olarak temizleyen bir pipeline yazdık.

Ders #2

  • main’in aynası olan versioned branch’i giderek daha zor klonlanır hale geldi. Yalnızca CHANGELOG.md ve CHANGELOG.json dosyaları değişmesine rağmen, 125GB ek git verisi getiriliyordu.
  • Linus Torvalds’ın commit ettiği eski paketleme kodunda, sıkıştırma sırasında yalnızca dosya adının son 16 karakterinin karşılaştırıldığı bir sorun keşfettik. Bu yüzden git, farklı paketlerdeki CHANGELOG.md dosyalarını birbirleriyle karşılaştırıyor ve tüm dosyayı tekrar tekrar push ediyordu.
  • Reponun boyutunu azaltmak için git repack -adf --window=250 komutunu kullandık; yeni git repack -adf --path-walk komutuyla boyutu 178GB’dan 5GB’a düşürdük.
  • git push sırasında doğru delta’ların üretilmesi için git config --global pack.usePathWalk true ayarını ekledik.

Kapanış

  • Büyük monorepolarda CHANGELOG.md gibi uzun adlı dosyalar sık güncelleniyorsa, path walk özelliğine dikkat etmek gerekiyor.
  • git survey komutuyla disk boyutuna göre en büyük dosyaları, şişirilmiş boyuta göre en büyük dizinleri ve benzer bilgileri görebilirsiniz.
  • Microsoft, repository büyümesi için çözümler geliştiriyor ve bunları dünya genelinde sunuyor.

GN⁺ Özeti

  • Bu yazı, büyük ölçekli bir JavaScript monoreposunun git boyutunu küçültme deneyimini paylaşıyor. Özellikle eski git paketleme kodundaki sorunu çözerek repo boyutunu büyük ölçüde azalttılar.
  • Yazı, büyük projelerde ortaya çıkabilecek git ile ilgili sorunları çözmek için faydalı bilgiler sunuyor. Özellikle CHANGELOG.md gibi dosyaların tekrar tekrar güncellenmesinden kaynaklanan problemleri nasıl çözeceğini anlatıyor.
  • Benzer amaçlara sahip projeler arasında Facebook’un Buck’ı ve Google’ın Bazel’i bulunuyor. Bu araçlar, büyük kod tabanlarını verimli yönetmeye yardımcı olabilir.

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-28
Hacker News yorumu

  • Yeni git-survey komutu henüz git.git içine dahil edilmedi. Microsoft’un Git fork’una eklenmiş durumda

  • nixpkgs klonlandığında, --window 250 seçeneği boyutu 1.7GB’a düşürdü. Microsoft Git fork’undaki --path-walk seçeneği ise 1.9GB’a düşürdü

    • Her iki seçenek de başlangıç boyutunun yarısından daha aza indirdi
    • Bunu GitHub’da çalıştırabilmek güzel olurdu; insanların bunu kontrol edebileceği bir şekilde barındırılması ise daha da iyi olurdu

  • Avrupa’daki bazı kullanıcılar büyük repoları klonlayamadıklarını söylüyor. Sunucu tarafında değişiklik yapılana kadar klonlama mümkün görünmüyor

  • Dosya adlarında tam yolun yer almaması şeklindeki bir hata yüzünden sorun çıktı. Sadece son 16 karakter kontrol ediliyordu

  • Derick Stolee, Git’in iç yapısı hakkında bir blog yazdı. Yerelde ve CI’da git clone boyutunu nasıl azaltabileceğimiz konusunda ondan çok şey öğrenilebildi

  • Git’i hacklemek eğlenceli ama 2.500 paketi monorepo’ya dahil etmemenin bir yolu olup olmadığını merak ediyorum

  • Microsoft’un Azure DevOps’u kendi içinde kullanması iyi olur. Azure servisleri yalnızca GitHub’a yerel konektör sağlıyor gibi görünüyor

  • Git’in iç yapısını çok iyi bilen birinin yakında olması, büyük projelerde çalışırken güzel bir avantaj

  • Bu gönderi için teşekkürler. Açık kaynak yazılıma büyük katkı sağladı. Microsoft, GitHub ve GitLab pek çok iyi şey sunuyor

  • Son 16 karakter ve tam yol kontrolü meselesini daha iyi anlamak istiyorum. Bunun delta sıkıştırma, paket indeksi ve çoklu paket indeksiyle nasıl bağlantılı olduğunu merak ediyorum