Incremental build — avvalgi build natijalaridan foydalanib, faqat o‘zgargan input va ularga bog‘liq qismlarni qayta yaratish usulidir. To‘liq clean build barcha artefaktni boshidan hosil qilsa, incremental yondashuv dasturchining kichik o‘zgarishdan keyingi kutish vaqtini sezilarli kamaytiradi. Uning to‘g‘riligi dependencylarni aniq kuzatishga bog‘liq.
O‘zgarishni aniqlash
Oddiy tizim file modification time va size’ni solishtiradi. Bu tez, ammo clock farqi, faylni eski timestamp bilan tiklash yoki kontent o‘zgarmagan touch sabab xato qaror berishi mumkin. Content-based tizim input digestini hisoblab, haqiqiy bayt o‘zgarishini aniqlaydi.
Source’dan tashqari compiler versiyasi, flag, environment, generated config va dependency ham action inputidir. Ular cache keyga kirmasa, build “up to date” deb noto‘g‘ri eski outputni qaytaradi. Yashirin input incremental buildning eng qiyin xatolaridan biridir.
Invalidation
Bir node inputi o‘zgarsa uning actioni va downstream consumerlari invalid bo‘ladi. Header fayldagi private implementation o‘zgarishi ham unga bog‘langan ko‘p C/C++ compilation unitni qayta build qilishi mumkin. Module interface va implementationni ajratish invalidation radiusini kamaytiradi.
Over-invalidation to‘g‘ri natija beradi, lekin ko‘p ortiqcha ish qiladi. Under-invalidation esa tez, ammo noto‘g‘ri binary hosil qiladi. Build profiling qaysi o‘zgarish nega qaysi targetni qayta bajarganini tushuntirishi kerak.
Cache darajalari
In-memory daemon parsed graph va compiler state’ni saqlashi mumkin. Local disk cache action outputini mashinada qayta ishlatadi. Remote cache CI va jamoa orasida natijani bo‘lishadi. Distributed cacheda output digest bilan tekshiriladi va yozish huquqi ishonchli builderga cheklanadi.
Cache miss sababi input farqi, toolchain, platforma yoki nondeterministic command bo‘lishi mumkin. Faqat hit rate yetarli metrika emas; cache lookup latency, download hajmi va critical pathga ta’sir ham o‘lchanadi.
Compiler incrementalizmi
Ba’zi compilerlar bitta target ichida function yoki module darajasida o‘zgarishni kuzatadi. Stable interface bo‘lsa consumer qayta type-check qilinmasligi mumkin. Internal compiler cache formatini turli versiyalar orasida ishlatish xavfli bo‘lgani uchun compiler identity keyga kiradi.
Linker ham incremental linking orqali o‘zgargan objectlarni tez qo‘shishi mumkin, lekin release binary ko‘pincha toza yoki to‘liq optimallashtirilgan linkdan olinadi. Development tezligi va release reproducibility alohida profillarda boshqariladi.
To‘g‘rilikni tekshirish
Incremental va clean build natijasi bir xil deklaratsiyalangan input uchun funksional jihatdan teng bo‘lishi kerak. CI vaqti-vaqti bilan cache’siz clean build qilib, yashirin dependency yoki stale outputni topadi. Reproducible loyiha bitma-bit digestni ham solishtirishi mumkin.
Build action o‘z output katalogidan tashqariga yozmasligi va oldingi temporary faylga tayanmasligi kerak. Sandbox har action uchun toza muhit yaratib, incremental tasodifiy holatini kamaytiradi. Xato topilganda “clean qilib ko‘ring” vaqtinchalik diagnostika, lekin dependency muammosining doimiy yechimi emas.
Developer oqimi
File watcher o‘zgarishni ko‘rib, eng kichik tegishli targetni avtomatik qayta build va test qilishi mumkin. Editor integration diagnosticsni source qatoriga qaytaradi. Tez feedback developerga kichik change bilan ishlash imkonini beradi, lekin watcher event yo‘qotsa manual build bilan bir xil natija chiqishi kerak.
Incremental holat uzoq umr ko‘rgan daemon ichida saqlansa memory leak va stale graph kuzatiladi. Daemon restart natijani o‘zgartirmasligi, faqat performancega ta’sir qilishi kerak. CI clean build va selective incremental testni birga ishlatib, correctness hamda real developer yo‘lini tekshiradi. Cache statistics shaxsiy source path yoki secret commandni markaziy telemetryga oshkor qilmasligi lozim.
Bog‘liq tushunchalar
Build system, Build graph, Cache invalidation, Content hash, Remote cache, Hermetic build, Reproducible build