Build Süreci (Derleme) Nedir?
Kısa tanım
Build süreci (derleme), geliştiricinin yazdığı kaynak kodu ve bağımlılıkları, sunucuda veya tarayıcıda çalıştırılabilecek ve yayına alınabilecek bir çıktıya dönüştüren otomatik adımların bütünüdür. Web projelerinde bu adımlar tipik olarak bağımlılıkların kurulmasını, TypeScript gibi dillerin JavaScript'e çevrilmesini, dosyaların paketlenip küçültülmesini ve statik sayfaların üretilmesini kapsar. Sonuç, sürümlenebilen bir build çıktısı (artifact) olur.
Diğer adları: Build Süreci, Build, Derleme Süreci, Build Process, Production Build
Kaynak kod ile çalışan program arasındaki yol
Geliştiricinin editörde yazdığı kod, çoğu zaman olduğu gibi çalıştırılmaz. Go veya Java gibi derlenen dillerde build, kaynağı çalıştırılabilir bir ikili dosyaya ya da paket arşivine çevirir. Web dünyasında ise “build” denince daha çok tarayıcıya ve sunucuya gönderilecek dosyaların hazırlanması anlaşılır. Modern bir web projesinde tipik adımlar şunlardır:
- Bağımlılıkların kurulması: Kilit dosyasındaki (
package-lock.jsongibi) sürümler birebir kurulur. - Dönüştürme: TypeScript ve JSX, tarayıcının anlayacağı JavaScript'e çevrilir; tip hataları bu aşamada yakalanır.
- Paketleme (bundling): Yüzlerce modül, tarayıcının verimli indirebileceği daha az sayıda dosyada birleştirilir. Kullanılmayan kod tree shaking ile ayıklanır, sayfalara göre parçalara bölünür.
- Optimizasyon: JavaScript ve CSS küçültülür, görseller yeniden boyutlandırılır, kritik CSS ayrılır.
- Ön üretim: İçeriği istekten bağımsız olan sayfalar HTML olarak önceden üretilir.
- Çıktı: Tüm bunlar, yayına alınacak tek bir klasör veya container imajı hâline gelir.
Hash'li dosya adları ve önbellek
Build araçları üretilen dosyaların adına içeriklerinden hesaplanan bir özet ekler: app.js yerine app.3f9a1c7e.js. İçerik değişmedikçe ad da değişmez. Bu sayede bu dosyalar tarayıcıda ve CDN'de çok uzun süre önbellekte tutulabilir:
Cache-Control: public, max-age=31536000, immutableYeni bir sürüm çıktığında değişen dosyalar yeni adlar alır, HTML de bu yeni adlara işaret eder. Kullanıcı eski önbelleğe takılmadan güncel dosyaları indirir.
Build zamanı ve çalışma zamanı değişkenleri
Build sürecindeki en sinsi hata kaynaklarından biri, değişkenlerin ne zaman okunduğudur. Sunucuda çalışan kod ortam değişkenlerini genellikle çalışma anında okur. Tarayıcıya gönderilen kodda ise değer build sırasında dosyanın içine gömülür. Next.js'te NEXT_PUBLIC_ ile başlayan değişkenler bu şekilde çalışır: build alındıktan sonra değiştirilmeleri, yeniden build alınmadıkça hiçbir etki yaratmaz. İki pratik sonucu vardır:
- Aynı build'i hem staging hem canlı ortamda kullanmak istiyorsanız, ortama göre değişen değerleri tarayıcı koduna gömülmeyecek şekilde tasarlamalısınız.
- Gizli bir anahtarın yanlışlıkla tarayıcıya açık bir değişkene konması, onu build çıktısındaki herkesin okuyabileceği bir JavaScript dosyasına yazar.
Tekrarlanabilir build
“Benim makinemde çalışıyordu” sorununun çoğu, build'in her yerde farklı sonuç vermesinden doğar. Bunu önlemenin yolları bellidir: bağımlılık sürümlerini kilit dosyasıyla sabitlemek, npm install yerine kilit dosyasına sadık kalan npm ci kullanmak, Node.js gibi araçların sürümünü proje içinde belirtmek ve build'i geliştirici bilgisayarında değil, temiz bir CI/CD ortamında almak.
Bunun bir adım ötesi “bir kez build al, her yere aynısını dağıt” ilkesidir. Test edilen artifact ile canlıya çıkan artifact aynı olmalıdır; canlı için ayrıca build almak, test edilmemiş bir paketi yayına almak demektir.
Build süresi uzadığında
Proje büyüdükçe build dakikalar sürebilir ve bu, her değişikliğin geri bildirimini geciktirir. Bağımlılık klasörlerini ve derleyici önbelleklerini CI'da saklamak, değişmeyen paketleri yeniden derlememek ve container imajlarında katman sırasını önbelleğe uygun kurmak süreyi belirgin biçimde kısaltır.