Webpack İpuçları #2: Speed Measure ile Build Sürelerini Ölçmek
Webpack serisindeki bir önceki yazı: Webpack İpuçları #1: Bundle Analyzer ile Bundle Dosyalarını Analiz Etmek
Geçtiğimiz haftaki yazıda Webpack kullanarak oluşturulan bundle dosyalarının görselleştirilerek analiz edilmesini sağlayan Webpack eklentisi, Webpack Bundle Analyzer’dan bahsetmiştim.
Hatırlarsak oradaki motivasyon, proje büyüdükçe bağımlılıkların da artması ve beraberinde bundle dosyalarında hangi modüllerin yer aldığını, bunların hangilerine gerçekten ihtiyaç duyulup duyulmadığını elle yönetmenin pek mümkün olmamasıydı. Bu aşamada oluşacak ihmaller kaçınılmaz olarak bundle dosyalarının boyutlarının büyümesine ve son kullanıcının hoş olmayan deneyimler yaşamasına neden oluyordu. Webpack Bundle Analyzer ile o problemleri çözdüğümüzü varsayalım.
Uzayan Build Süreleri
Yine projeler büyüdükçe karşılaşılabilecek bir başka sorun da uzayan build süreleridir. Bu sorun elbette kendiliğinden var olmaz, bir dizi işlemin sonucu olarak meydana gelir. Birçok sebebi olabilir. En popülerlerini birkaç maddeyle özetlemek gerekirse;
- SASS/LESS gibi CSS ön işleyicilerinin mükerrer ve performanssız kullanılması,
- Hatalı ve/veya gereksiz Webpack loader yapılandırmaları,
- Dosya sistemi üzerindeki pahalı operasyonlar,
- Pre-render işlemleri,
- Güncel olmayan bundler kullanımı
build sürelerinin uzamasına neden olabilir.
Build Süreleri Uzarsa Ne Olur?
Peki neden bu sürelerin uzamasını dert etmeliyiz, birkaç maddeyle de onları listeleyelim. En masumlarından daha maliyetli olanlara doğru gidelim;
- Geliştirme ortamında hot reload gibi, bundle dosyalarının yeniden oluşturulması gereken operasyonlarda artan bekleme süreleri,
- Projeler arasında geçiş yapılması gerektiğinde uygulamaların ilk ayağa kalkma sürelerinin uzaması,
- CI/CD pipeline sürelerinin uzamasının getirdiği maliyetler,
- Deploy/release periyotlarının uzaması.
İlk iki madde doğrudan geliştiriciyi etkileyen daha hafif nedenler. Geliştirici, kendi deneyimini göz ardı ederek hayatına devam edebilir elbette. Fakat üçüncü ve özellikle dördüncü maddeler, projenin deploy edilme sürecini birçok açıdan sıkıntıya sokacaktır.
CI/CD, Pipeline, Deploy, Release ve Diğer Ölümcül Şeyler*
Günümüz DevOps pratikleriyle CI/CD pipeline’lar kurguluyor, projelerimizi bu pipeline’lar aracılığıyla geliştirme ortamından production (canlı) ortama kadar süren bir yolculuğa çıkarıyoruz. Bu esnada build işlemlerimizi yapıyor, testlerimizi çalıştırıyor ve güvenlik kontrollerimizi gerçekleştiriyoruz. Günün sonunda bir sorunla karşılaşmadığımız takdirde değişikliklerimiz son kullanıcıya ulaşıyor.
Fakat görüleceği üzere bu birçok adımı olan, karmaşıklaşmaya müsait bir süreç ve bu sürecin ne kadar zaman alacağı kurguladığımız ve işlettiğimiz pipeline ile doğrudan ilintili.
Deploy Periyotlarının Uzaması
Çevik yazılım geliştirme yöntemleriyle olabildiğince hızlı, doğru ve somut çıktıları olan, müşteri ihtiyaçlarını karşılamaya yönelik geliştirmeler yapmak niyetindeyiz. Fakat bunu geleneksel deploy yöntemleriyle yapmak oldukça zor. Uzun periyotlar ve meşakkatli süreçler buna mâni olmakta. O nedenle deploy sürecini günlük işlerimizin bir parçası hâline getirecek, handiyse varlığını dahi unutacağımız yapılar hazırlamak durumundayız ki uzun periyotları bir kenara bırakalım, gün içerisinde dahi gönül rahatlığıyla defalarca kez projemizi deploy edebilelim. Bunun da yolu yine günün sonunda sürelere çıkmakta. Kimse bir saat sürecek deploy sürecini günde defalarca işletmeye kolay kolay gönüllü olmayacaktır.
Maliyetlerin Artması
Bir diğer konu da maliyet. Pipeline’ları bize sağlayan servis sağlayıcılar ödeme planlarını diğer yan faydalarla birlikte ekseriyetle pipeline’ların süresiyle belirliyorlar. Örneği GitLab, ücretsiz planında aylık 400 dakikalık bir CI/CD pipeline‘ına izin verirken Premium planında 10.000 dakika, Ultimate planında ise 50.000 dakikaya kadar hak tanımakta.
Webpack Speed Measure
Çok uzun bir girizgâhdan sonra ana konuya gelirsek ki tahminim girizgâhdan çok kısa sürecek; Webpack Speed Measure eklentisi.
Speed Measure, Webpack yapılandırmamızı sarmalayarak tüm build operasyonlarının kendi üzerinden geçmesini sağlıyor. Bu sayede hangi işlemin ne kadar sürdüğünü, tıkanan noktaları bize CLI üzerinden ekstra bir efora ihtiyaç duymadan gösterebiliyor.
Mevcut bir Webpack yapılandırmamız olduğunu varsayarak hızlıca bir örnek yapalım. Webpack Speed Measure’ı geliştirme ortamı bağımlılığı olarak kuralım.
Mevcut Webpack yapılandırma dosyamıza import edelim.
Webpack yapılandırmamızın tutulduğu objeyi import ettiğimiz Speed Measure eklentisiyle sarmalayalım.
Akabinde her zaman olduğu gibi geliştirme ortamı veya production ortam için bir build alalım.
Görüleceği gibi Webpack Speed Measure, bize birtakım süreler verdi. Bunlardan ilki tüm build işleminin ne kadar sürdüğü. Hemen sonrasında ise Webpack yapılandırmasında yer alan eklenti ve loader işlemlerini ayrıştırarak toplam build süresinin ne kadarını kullandıklarını analiz etti.
Örnekteki süreler her ne kadar çok kısa gibi gözükse de bu işlemin günde defalarca yapılacağı düşünüldüğünde tablo değişmekte. Webpack Speed Measure’ı son uyguladığım projede, majör olmayan müdahalelerle %45'e yakın bir tasarruf elde ettim. Bu da neredeyse her iki deploy sürecinden birinin yaşanmadığı bir kaynak ve zaman tüketimini işaret etmekte.
Kaynaklar
https://www.npmjs.com/package/speed-measure-webpack-plugin
https://github.com/stephencookdev/speed-measure-webpack-plugin
https://about.gitlab.com/pricing
Webpack serisindeki bir sonraki yazı: Webpack İpuçları #3: Canlı Ortama Çıkarken Konsol Loglarını Temizlemek
