Vercel, deployment'lar arasında dependency doğrulamasını yeniden kullanarak pnpm install sürelerini %14 kısalttı

Vercel, platformundaki pnpm dependency install'larını, doğrulama sonuçlarını deployment'lar arasında yeniden kullanarak hızlandırdı. Vercel blog'unda yayımlanan bir changelog gönderisine göre, build cache'i geri yüklenen Pro deployment'larında bu optimizasyonun etkinleştirilmesiyle ortalama install süreleri %14 düştü ve en iyi durumda install'lar artık milisaniyeler içinde tamamlanabiliyor.

Optimizasyon nasıl çalışıyor

Bir projenin build komutu çalışmadan önce Vercel projenin dependency'lerini kurar ve pnpm projelerinde bu kurulum, lockfile'ı supply-chain politikalarına karşı kontrol eden bir doğrulama aşaması içeriyordu. Kurulumun devam edebilmesi için lockfile'daki her girdinin bu kontrollerden geçmesi gerekiyor ve bu işin her deployment'ta yeniden yapılması zaman kaybettiriyordu. Vercel'in yayımladığı öncesi-sonrası örneğinde, 461 girdilik bir lockfile'ın doğrulanması 2,8 saniyelik install süresinin yaklaşık 2,5 saniyesini alıyordu.

Yapılan değişiklikle, başarılı bir doğrulama artık sonraki deployment'lara taşınıyor. Sonraki bir build aynı dependency'leri kullandığında Vercel her girdiyi yeniden incelemek yerine önceki sonucu kullanıyor ve böylece install adımı neredeyse tüm işini atlayabiliyor. Aynı örnekte install artık yaklaşık 135 milisaniyede tamamlanıyor ve doğrulama çıktısı, lockfile'ın bir dakikadan kısa süre önce kontrol edildiğini belirtiyor. Her iki rakam da pnpm v12.3.4 kullanan build'lerden geliyor.

Dependency'ler paket eklenmesi, güncellenmesi veya kaldırılmasıyla değiştiğinde, daha önce olduğu gibi taze bir doğrulama çalışıyor; yani hızlı yol yalnızca önceki sonuç mevcut lockfile için hâlâ geçerliyken uygulanıyor.

Rakamlar neyi kapsıyor

%14 rakamı, Vercel'in build cache'inin geri yüklendiği Pro planı deployment'ları arasında ölçtüğü bir ortalama. Bu ortalama ile milisaniye ölçeğindeki en iyi durum arasındaki fark, dependency'lerin gerçekte ne sıklıkla değiştiğini yansıtıyor: lockfile'a dokunan deployment'lar hâlâ tam bir doğrulama turunun bedelini öderken, yalnızca uygulama kodunu değiştiren commit'ler en fazla yararı görüyor çünkü dependency setleri önceki build ile birebir aynı.

Şirkete göre bu iyileştirme tüm planlarda mevcut ve herhangi bir yapılandırma gerektirmeden otomatik olarak uygulanıyor.

Neden önemli

Install süresi her deployment'ta ödenen bir vergidir; bu yüzden kazanılan birkaç saniye bile bir ekibin her gün yaptığı build'lerde katlanarak büyür. CI çalışmaları, preview deployment'ları ve production sürümlerinin hepsi aynı dependency adımıyla başlar ve bu adımın kısalması, bir commit'i push'lamaktan sonucu görmeye kadar giden geri bildirim döngüsünü sıkılaştırır.

Daha ilginç olan kısım ise bunun supply-chain güvenliği ile build hızı arasındaki dengeye etkisi. Lockfile politika kontrolleri, istenmeyen veya güvenliği ihlal edilmiş paketlerin build'e girmesini engellemek için vardır; ancak her deployment'a gecikme ekledikleri için zayıflatılmaları veya atlatılmaları yönünde baskı yaratırlar. Başarılı bir doğrulamanın yeniden kullanılması, kontrolü yerinde tutarken yinelenen maliyetinin büyük kısmını ortadan kaldırıyor: ekipler her deploy'da kontrolün bedelini yeniden ödemeden, incelenmiş bir lockfile'a kavuşuyor. Doğruladığı artefakta anahtarlanmış pahalı bir güvenlik kontrolünü cache'leyip yalnızca o artefakt değiştiğinde yeniden çalıştırmak yaklaşımı, diğer build ve CI platformlarının da benimseyebileceği bir kalıp.

Bedeli ise doğrulamanın, gerçekten son çalıştırıldığı an kadar taze olması. Vercel'in çıktısı bunu, lockfile'ın en son ne zaman doğrulandığını bildirerek görünür kılıyor ve dependency'lerdeki herhangi bir değişiklik, yeniden kullanılmış bir sonuç yerine tam bir yeniden kontrol tetikliyor.