Перейти до вмісту

Build

Матеріал з K2 ERP Wiki

Build і deployment — різні етапи.; істотно: build configuration має бути явною.; - uses: actions/checkout@v4 

* debugging;
* error tracking;
* production stack traces;
* frontend monitoring;
* QA.; Build performance важливий для developer experience.; '''Build once, deploy many''' — практика, де artifact збирають один раз, а потім просувають через environments.;</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<syntaxhighlight lang="bash">

== Джерела ==

</div>

'''Build logs''' — записи про те, що відбувалося під час build.; Сотні warnings роблять справжню проблему невидимою.; * зрозуміти, що deployed;
* debug-ити bugs;
* робити rollback;
* зв’язати artifact із commit;
* вести release notes;
* підтримувати users;
* audit-ити production.; Run tests

Добре, якщо є собою:

* security;
* audit;
* trust;
* open source;
* supply chain verification;
* debugging;
* release confidence.; Захист:
COPY .; ↓
'''Небезпека:''' нестабільний build підриває довіру до CI.;== Приклад Docker build ==

OS: linux, windows, macos
завдяки наявності '''Практична роль:''' build matrix користувачі можуть перевірити, що проєкт функціонує не тільки в одному ідеальному середовищі.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== Build у DevOps ==
Deploy same artifact to staging
'''Практична роль:''' minification робить frontend artifact компактнішим для користувача.; Linking має змогу бути:
'''Практична роль:''' pipeline робить build не ручним ритуалом, а повторюваним процесом.; * до build;
* під час build;
* після build;
* на artifact;
* у окремому pipeline stage.; "test": "vitest run",
docker build -t my-app:1.0.0 .; - main

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

 "builtAt": "2026-05-09T12:00:00Z"

* package manifests;
* lock files;
* version constraints;
* dependency resolution;
* private registries;
* vulnerability scanning;
* license scanning;
* dependency caching;
* transitive dependencies.; Він тісно пов’язаний із reproducible build.; '''Build configuration''' визначає, як саме виконувати build.; Приклад

* це маленький script;
* немає compilation;
* немає dependencies;
* це навчальний проєкт;
* немає production;
* немає release artifact;
* достатньо запуску interpreter.; FROM node:22-alpine AS runtime

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

переважні аспекти:

* flaky builds;
* повільний build;
* неповні dependencies;
* різні результати локально й у CI;
* secrets у artifact;
* вразливі dependencies;
* погані cache keys;
* non-reproducible output;
* failed release через build config;
* build функціонує тільки на одному machine;
* artifact не збережено;
* відсутній version metadata;
* відсутні tests;
* broken lock file.; * C → machine code;
* C++ → machine code;
* Rust → machine code;
* Go → binary;
* Java → bytecode;
* C# → intermediate language;
* Swift → native code.; Production build зазвичай:

== Тематичні мітки ==

Типи перевірок:

'''істотно:''' dev build зручний, але він має змогу бути повільним, небезпечним або занадто відкритим для production-середовища.; FROM nginx:alpine

* IPA;
* archive;
* signed build.;</div>

tree shaking tries to include only needed parts

* є собою дивна помилка;
* cache має змогу бути пошкоджений;
* потрібно перевірити reproducibility;
* CI має збирати з нуля;
* release має бути максимально чистим;
* залежності змінилися.; Етап

Build у monorepo має змогу потребувати:

!; * environment;
* target platform;
* compiler flags;
* optimization level;
* feature flags;
* dependency versions;
* output path;
* debug symbols;
* signing keys;
* architecture;
* runtime;
* secrets references;
* build arguments.; Приклади:
{
 ↓

</div>

dist/

фабрики: що з чого робити забезпечується через '''Проста аналогія:''' build system — це інструкція; додатково реалізовано у якому порядку й якими інструментами.; '''Production build''' — build, оптимізований для реального використання користувачами.; Build часто пов’язаний із tests.;

Build у Release Management

</div>

|- | Java | Maven, Gradle |- | JavaScript/TypeScript | npm, pnpm, Yarn, Vite, Webpack, Rollup |- | C/C++ | Make, CMake, Ninja, Bazel |- | Rust | Cargo |- | Go | go build |- | .NET | MSBuild, dotnet CLI |- | Python | setuptools, Poetry, Hatch, build |- | Android | Gradle |- | iOS | Xcode build system, xcodebuild |}

main bundle

Build Pipeline

Способи покращення:

Ризики: {{SEO


Недоліки: 

Run unit tests
'''Критично:''' release build має бути зібраний контрольовано, перевірено й збережено як artifact.;<syntaxhighlight lang="dockerfile">
Security scan виконується
Production build не містить secrets

<syntaxhighlight lang="text">

* TypeScript;
* Java;
* C#;
* Rust;
* Go;
* Kotlin;
* Scala;
* typed Python у частині сценаріїв;
* API contracts.; '''істотно:''' mobile release build часто залежить не тільки від коду, а й від правильного signing і store metadata.;== Mobile Build ==

* dependency pinning;
* secret scanning;
* build isolation;
* signed artifacts;
* provenance;
* SBOM;
* least privilege CI tokens;
* trusted builders;
* review of build scripts;
* protected branches.; Приклади runtime дій:

* легше debug;
* швидше розробляти;
* кращі error messages.; * прибрати пробіли;
* скоротити імена;
* прибрати comments;
* оптимізувати expressions;
* зменшити bundle size.; Але secrets не варто випадково вшивати в frontend або public artifact.; * cache invalidation;
* ризик stale output;
* складність dependency graph;
* іноді важче debug.; * compromised dependency;
* malicious package;
* poisoned cache;
* tampered artifact;
* stolen signing key;
* leaked CI token;
* unsafe build script;
* untrusted pull request;
* vulnerable base image.;<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

* signing certificates;
* provisioning profiles;
* app version;
* build number;
* permissions;
* native dependencies;
* assets;
* store requirements;
* release channels.; Якщо цей міст хиткий, навіть хороший код має змогу не дійти до користувача без проблем.;</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Приклад:

</div>

* менше різниць між environments;
* artifact уже протестований;
* простіший audit;
* кращий rollback;
* менше “але в staging був інший build”.; Build application
debug
Приклади:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''істотно:''' source maps корисні, але для production потрібно вирішити, чи вони public, private або завантажуються тільки в error monitoring service.; '''Практична роль:''' reproducible build надає можливість перевірити, що artifact справді відповідає source code, а не випадковим умовам збірки.;== Build Matrix ==

'''Build''' — це бізнес-процес перетворення source code, dependencies, assets і configuration у готовий artifact.; Небезпечно, коли результат залежить від випадкових локальних налаштувань.;</div>
== Цікавий факт ==
</div>

== Build і Tests ==
'''Linting''' перевіряє стиль, помилки й потенційно небезпечні patterns у коді.; * Clean build часто знаходить проблеми, які приховував cache.;

Signing Build Artifact

Коли Build особливо важливий

Runtime: node 20, node 22

  • автоматизувати build;
  • запускати build у CI;
  • використовувати lock files;
  • зберігати artifacts;
  • додавати version metadata;
  • не збирати release вручну на ноутбуці;
  • використовувати clean build для release;
  • відокремлювати build і deploy;
  • тестувати artifact;
  • сканувати dependencies;
  • не включати secrets;
  • підписувати critical artifacts;
  • створювати SBOM для важливих релізів;
  • використовувати build cache обережно;
  • документувати build commands;
  • контролювати build environment;
  • робити build once, deploy many.; Практична порада: якщо build функціонує тільки на одному ноутбуці, це не build process, а локальна традиція.; Build provenance — відомості про походження build artifact.;</syntaxhighlight>

Upload artifact

Інструменти:

  • `1.4.2`;
  • `1.4.2+105`;
  • `2026.05.09`;
  • `git-a1b2c3d`;
  • `build-3481`;
  • `v2.0.0-rc.1`.; істотно: provenance сприяє довести, що artifact створено з правильного коду правильним pipeline.; Потрібно контролювати:
  • dependency vulnerability scan;
  • container image scan;
  • secret scanning;
  • static application security testing;
  • license compliance;
  • SBOM generation;
  • infrastructure scanning;
  • malware scanning у частині scenarios.; В open source build має бути зрозумілим для contributors.; * containerized builds;
  • pinned versions;
  • lock files;
  • CI builds;
  • infrastructure as code;
  • version managers;
  • reproducible environments.; ↓

linux-amd64

library exports 100 functions 

- name: Build
  • automation;
  • repeatability;
  • artifact storage;
  • traceability;
  • CI/CD;
  • security scanning;
  • deployment promotion;
  • rollback;
  • environment parity;
  • observability;
  • release governance.; Він повинен працювати в CI, використовувати lock files, не включати secrets, створювати versioned artifacts і дозволяти команді знати, що саме було зібрано, протестовано й розгорнуто.; ↓

Типові помилки початківців

Рекомендовано:

COPY --from=build /app/dist /usr/share/nginx/html Release build створюється не вручну

Build System

  • base image;
  • dependency installation;
  • copying source code;
  • running build commands;
  • setting environment;
  • exposing ports;
  • defining startup command;
  • multi-stage builds.;

Build часто має version або build number.; Практична роль: production build — це реліз, яка має бути швидкою, стабільною й безпечною для користувачів.; run: npm test

RUN npm ci --omit=dev

Source maps допомагають пов’язати minified або bundled code з original source.; CMD ["node", "dist/server.js"]

  • повільніший;
  • більший artifact;
  • не підходить для production;
  • має змогу містити зайву діагностику.;== Compiler ==

Version metadata сприяє:

</syntaxhighlight>

  • Документація build tools, compilers, bundlers і package managers.; * push;
  • pull request;
  • merge;
  • tag;
  • release;
  • schedule;
  • manual trigger.; Найлюдяніший факт: build — це момент істини: код перестає бути без ускладнень набором файлів і стає чимось, що можна реально запустити.; Environment variables часто використовуються під час build.; Transpiler перетворює код з однієї мови або версії мови в іншу мову або іншу версію.; windows-x64

Reproducibility ускладнюють: Clean build корисний, коли:

Tree Shaking

  • автоматизація процесів;
  • повторюваність;
  • створення artifacts;
  • перевірка коду;
  • зменшення ручних помилок;
  • швидший release;
  • CI/CD integration;
  • security scanning;
  • versioning;
  • traceability;
  • rollback support;
  • контроль dependencies;
  • кращий developer workflow;
  • однаковий output для команди.;
    <syntaxhighlight lang="bash">

* README build instructions;
* lock files;
* supported platforms;
* CI status;
* clear dependencies;
* reproducible commands;
* tests;
* release process;
* troubleshooting section.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

!; Build є собою центральною частиною software delivery, CI/CD і release management.; * syntax issues;
* unused variables;
* suspicious code;
* formatting problems;
* unsafe patterns;
* accessibility issues у frontend;
* dependency issues у частині інструментів.; Build on Linux x64 → output for ARM device
<syntaxhighlight lang="bash">
Release management використовує build для створення офіційної версії продукту.; production
RUN npm ci
'''Code splitting''' розбиває application bundle на частини.; Інакше можна прискорити не те, що реально гальмує.; '''істотно:''' cache має прискорювати build, але не має змінювати його правильність.; Приклад:
Frontend build має змогу включати:

'''Практична роль:''' incremental build економить час розробника, бо не змушує щоразу збирати весь світ заново.;<syntaxhighlight lang="text">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

 }

Приклади lock files:

'''Підказка:''' якщо результат build не можна знайти, перевірити й повторити, build process варто покращити.; Dependencies

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Environment Variables у Build ==
Deploy same artifact to production
Команда запускає `npm run build`, отримує optimized files у `dist/`, завантажує їх на CDN або static hosting.; * різні versions Node.js;
* різні compilers;
* різні OS packages;
* різні environment variables;
* різні dependency registries;
* різні local config files;
* різні Docker base images.;== Build і Secrets ==
'''Проста думка:''' build artifact — це те, що залишилося після build і що можна реально використати далі.; '''Development build''' — збірка для локальної роботи.; Deploy або release
=== Frontend application ===
'''Проста різниця:''' compiler часто веде до lower-level output, а transpiler зазвичай переводить код у схожу або суміжну мову.; Pipeline запускає `mvn package`, створює `.jar`, запускає tests і публікує artifact у repository.; '''істотно:''' помилки linking часто з’являються не через синтаксис коду, а через неправильні libraries, symbols або build configuration.; Це сигнал, що pipeline зупинив потенційно погану зміну до release.;</div>
</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Build запускається однією командою

gcc main.c -o app
== Build Configuration ==
=== Java backend ===

CI build має змогу стартувати при:
'''Головна думка:''' не треба збирати production artifact окремо після testing.; '''Головна думка:''' build — це міст між кодом і реальним продуктом.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Docker build має змогу включати:

 ↓

* TypeScript → JavaScript;
* modern JavaScript → older JavaScript;
* JSX → JavaScript;
* Sass → CSS;
* Less → CSS.; застосовується для:
'''Практична роль:''' CI build перевіряє, що проєкт збирається не тільки на комп’ютері автора змін, а й у чистому контрольованому середовищі.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

</div>

rm -rf dist node_modules/.cache

jobs:

* довгого feedback loop;
* менш частих tests;
* більших pull requests;
* роздратування команди;
* обходу CI;
* нижчої продуктивності.; * Build logs можуть бути цінними для debugging, але небезпечними, якщо в них потрапили secrets.;== Development Build ==

Scan image
</div>

== Build і Type Checking ==
переважні аспекти:
 ↓
Build особливо важливий, якщо:
out/

 ↓
<syntaxhighlight lang="text">
застосовується в:

main.o + utils.o + library.a → app executable
'''Практична роль:''' frontend build перетворює код розробника на файли, які браузер має змогу оперативно завантажити.; * checkout code;
* install dependencies;
* lint;
* test;
* build;
* scan;
* upload artifacts;
* deploy preview;
* publish image.;<syntaxhighlight lang="bash">
'''Практична роль:''' checklist сприяє перетворити build із випадкового набору команд на надійний бізнес-процес.; Приклад:

 "ci": "npm run lint && npm run test && npm run build"

* source repository;
* commit;
* branch або tag;
* build system;
* builder identity;
* dependencies;
* build time;
* build command;
* test results;
* artifact hash;
* signature.; Build metadata має змогу містити:
Приклади build-time дій:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

 runs-on: ubuntu-latest

Це надає можливість:

'''Практична роль:''' bundler перетворює багато frontend-файлів у формат, який браузер має змогу оперативно завантажити й виконати.; Не варто збирати release “на чиємусь ноутбуці”.; Приклади:

Android artifacts:

dotnet publish
 "version": "1.4.2",
'''істотно:''' deterministic build не виникає випадково.; Tests запускаються
Build artifact once
Compile / Transpile / Bundle

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''істотно:''' не плутайте build-time configuration і runtime configuration.;</div>
Deploy staging
Build функціонує в CI

== Приклад CI build pipeline ==

'''Практична роль:''' static build створює сайт, який можна розмістити на CDN або static hosting без постійного backend rendering.; Приклад:
CI створює Android AAB або iOS archive, підписує build і відправляє в testing channel або app store process.; '''істотно:''' monorepo без розумного build system має змогу стати дуже повільним.;<syntaxhighlight lang="bash">

Приклад:
name: Build
Type checking перевіряє відповідність типів.; Store artifact

== переважні аспекти Build Process ==
Підписування сприяє перевірити:
</div>

Приклад frontend:

має змогу містити:

Build matrix корисна для:

* визначати targets;
* запускати compiler;
* керувати dependencies;
* запускати tests;
* кешувати результати;
* будувати artifacts;
* виконувати scripts;
* працювати з multi-module projects;
* підтримувати incremental builds.;</div>

</div>

 build:

'''SBOM''' або '''Software Bill of Materials''' має змогу створюватися під час build.;== Static Site Build ==

== Build і Supply Chain Security ==

* TypeScript compilation;
* JSX transformation;
* bundling;
* minification;
* tree shaking;
* CSS processing;
* image optimization;
* font handling;
* code splitting;
* source maps;
* static asset hashing.; Build optimization має змогу стосуватися:
== Cross-Compilation ==
<syntaxhighlight lang="bash">
</div>
'''Практична роль:''' backend build створює artifact, який можна запустити на сервері або в container.;</div>

</div>

* `.env` у Docker image;
* private key у mobile package;
* API token у frontend bundle;
* password у build log;
* cloud credentials у artifact;
* secret у source map.; dashboard chunk
має змогу включати:

Secrets не повинні потрапляти в build artifact або build logs.; Не кожному pet project потрібен Bazel, але кожному production-проєкту потрібна повторюваність.; '''Практична роль:''' простий build process знижує бар’єр входу для нових contributors.; програмний пакет

 ↓

'''Головне правило:''' хороший build має бути автоматичним, повторюваним, перевіреним, зрозумілим і не залежати від магії конкретного комп’ютера.; Приклади за екосистемами:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Run integration tests

Release build має змогу включати:

</div>

* hot reload;
* source maps;
* fast rebuild;
* dev server;
* mock data;
* verbose warnings;
* local API endpoints;
* relaxed optimization.;</div>

Bundler має змогу робити:
Build system має змогу:
Приклад:

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

 ↓

'''Практична роль:''' linting ловить частину проблем до того, як вони потраплять у artifact.;
  • вважати його скомпрометованим;
  • rotate secret;
  • перевірити logs;
  • перевірити artifacts;
  • видалити небезпечні copies;
  • оновити pipeline.; ↓

Build можна повторити на clean environment Reproducible build — build, який із однакового input створює однаковий output.; У software development build має змогу створювати executable file, library, mobile app package, Docker image, frontend bundle, backend artifact, static site, firmware image або release package.; "commit": "a1b2c3d",

Release Build

Build warning не завжди зупиняє build, але має змогу вказувати на проблему.; Користувачі майже ніколи не бачать source code.; істотно: release build має бути traceable: команда повинна знати, з якого commit, коли й ким він був створений.; Artifact зберігається в repository або registry </syntaxhighlight>

істотно: без lock file build має змогу сьогодні зібратися з одними dependencies, а завтра — з іншими.;

</syntaxhighlight>

Практична роль: build tool автоматизує повторювані кроки, які вручну були б повільними й помилковими.;

  • binaries;
  • packages;
  • mobile apps;
  • container images;
  • firmware;
  • installers.; Хороший build process має бути автоматизованим, повторюваним, контрольованим, безпечним і зрозумілим.;
  • packages;
  • versions;
  • dependencies;
  • licenses;
  • hashes;
  • supplier info;
  • relationships.; Проста аналогія: tree shaking — це струсити з дерева сухі гілки, які застосунок не використовує.; Причини:

SBOM описує:

Основна ідея: build перетворює код і ресурси проєкту на конкретний artifact, який можна перевірити, передати, встановити або запустити.; Приклад:

  • documentation sites;
  • blogs;
  • marketing websites;
  • Jamstack;
  • frontend apps;
  • static exports;
  • landing pages.;

Pipeline створює Docker image, сканує його, підписує й пушить у container registry.; Практична порада: build failure — це не без ускладнень перешкода.; * dependency graph;

  • affected builds;
  • remote caching;
  • task orchestration;
  • parallel execution;
  • package boundaries;
  • incremental checks;
  • selective testing.; * Матеріали щодо reproducible builds, deterministic builds, build cache, dependency locking і software supply chain security.;== Ризики Build Process ==

Приклад checklist для Build

↓

Deterministic Build

істотно: якщо clean build функціонує, а incremental build ні, проблема має змогу бути в cache або dependency tracking.; є собою зрозумілий README для build process Приклад: Debug build — збірка для розробки й налагодження.; Вони отримують результат build: застосунок у телефоні, `.exe` файл, сайт у браузері, Docker image на сервері або package у package registry.; * не мати build script;

  • збирати production вручну;
  • не використовувати lock file;
  • commit-ити `dist/` без потреби;
  • не знати, який artifact deployed;
  • не запускати tests у build;
  • вшивати secrets у artifact;
  • плутати dev build і production build;
  • ігнорувати build warnings;
  • не зберігати artifacts;
  • не мати version metadata;
  • не перевіряти Docker image size;
  • використовувати `latest` без контролю;
  • не чистити cache при дивних помилках;
  • не документувати build process.; Artifact має version metadata

Build artifact — результат build process.; Minification зменшує розмір JavaScript, CSS або HTML.; .; FROM node:22 AS build 

Static site build створює готові HTML, CSS і JavaScript файли.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
"без ускладнень запусти якось, у мене функціонує."
 "buildNumber": 3481,
{| class="wikitable"
<syntaxhighlight lang="bash">
</div>

'''Проста різниця:''' build створює “що запускати”, deployment визначає “де й як запускати”.; Приклади:
'''істотно:''' build logs потрібні для debugging, але їх не можна перетворювати на місце витоку tokens, passwords або private keys.; WORKDIR /app

* менший bundle;
* швидше завантаження;
* менше JavaScript для виконання;
* кращий frontend performance.;== Висновок ==

== Build Once, Deploy Many ==

* compile TypeScript;
* bundle assets;
* generate static pages;
* install dependencies;
* create image.;</div>
 ↓
 - name: Run tests

Minification має змогу:

</div>

== Bundler ==

* швидше локально;
* менше CPU;
* менше очікування;
* комфортно для великих проєктів;
* краще developer experience.; Недоліки:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Приклад:
== Build Provenance ==

Debug build часто має:

  • менший final image;
  • немає build tools у production image;
  • краща безпека;
  • чистіший runtime;
  • швидший deployment.; ↓

Incremental Build

Build Logs

Build pipeline — послідовність автоматизованих кроків для створення й перевірки artifact.; * Reproducible builds важливі для довіри до open source і security-sensitive software.; !; * APK;

  • AAB.; Development build не повинен випадково потрапляти в production.; переважні аспекти:

Transpiler

go build -o server ./cmd/server

Практична роль: Docker build пакує application і його runtime-залежності в image, який можна запускати однаково в різних середовищах.; Якщо команда звикає ігнорувати червоний pipeline, pipeline втрачає сенс.;== Коли Build має змогу бути простим == Основні переважні аспекти:

Cross-compilation — збірка програми для платформи, відмінної від платформи, на якій виконується build.;

public/

Build і Minification

Практична роль: швидкий build сприяє команді частіше перевіряти зміни й менше боятися запускати pipeline.; Він має змогу включати compilation, transpilation, bundling, linking, testing, scanning, packaging, signing і публікацію artifact.; * caching;

  • incremental builds;
  • parallelization;
  • remote cache;
  • dependency pruning;
  • test splitting;
  • faster tools;
  • smaller modules;
  • build profiling.; * process HTTP request;
  • connect to database;
  • read environment variable;
  • handle user action;
  • write logs.;
  • security response;
  • compliance;
  • vulnerability tracking;
  • supply chain security;
  • enterprise audits.;
  • compilation;
  • packaging;
  • dependency resolution;
  • static analysis;
  • tests;
  • migrations packaging;
  • Docker image build;
  • configuration validation;
  • artifact creation;
  • binary generation.; Погано:
'''Практична роль:''' compiler перетворює людський код на форму, яку має змогу виконати комп’ютер або runtime.; '''Головна перевага:''' build process перетворює “у мене функціонує” на “ми можемо це стабільно зібрати й перевірити”.; У Build pipeline часто передбачено security scanning.; Build має змогу бути простим, якщо:

* stale cache;
* cache poisoning;
* неправильні cache keys;
* різні результати локально й у CI;
* security risks у shared cache.;</div>
'''Критично:''' firmware build має бути дуже обережним, бо помилка має змогу зробити device непрацездатним або складним для відновлення.; DevOps звертає увагу на:
admin chunk
</div>

Linting під час build сприяє знайти:

</div>

</div>

<syntaxhighlight lang="bash">
Приклад:
'''Build system''' — платформа, яка описує, як саме збирати проєкт.; Create artifact
Ризики:
== Reproducible Build ==
<syntaxhighlight lang="text">

== Debug Build ==
'''Clean build''' — збірка з очищеного стану, без використання старих intermediate files або cache.; Це важливий етап між написанням коду й реальним використанням програми.;<syntaxhighlight lang="yaml">

'''Критично:''' build artifact має змогу містити вразливі dependencies або secrets.; '''Docker build''' створює Docker image з Dockerfile і build context.;
  • commit SHA;
  • branch;
  • build time;
  • build number;
  • CI job ID;
  • compiler version;
  • dependency versions;
  • target platform;
  • artifact checksum;
  • builder identity;
  • test status.;

Приклади:

Поширені помилки:

Architecture: x64, arm64

  • `NODE_ENV`;
  • `BUILD_ENV`;
  • `API_BASE_URL`;
  • `VERSION`;
  • `COMMIT_SHA`;
  • `FEATURE_FLAG`;
  • `PUBLIC_ANALYTICS_ID`.;

Firmware build створює software image для embedded devices.; У monorepo багато проєктів або packages живуть в одному repository.;

Build Docker image 

push:

Приклад простого build script

Build і Configuration Drift

Tests можуть запускатися: |- | Build | Створити artifact | Зібрати Docker image |- | Deployment | Запустити artifact у середовищі | Розгорнути image у Kubernetes |}

Build і Deployment

</syntaxhighlight> Build tool — конкретний інструмент, який запускає або керує build process.; * швидші builds;

  • менше навантаження;
  • ефективніші CI pipelines;
  • зручніше для monorepos.; run: npm ci
  • `package-lock.json`;
  • `pnpm-lock.yaml`;
  • `yarn.lock`;
  • `poetry.lock`;
  • `Cargo.lock`;
  • `go.sum`;
  • `Gemfile.lock`.;== Multi-Stage Build ==

Install dependencies

source code ≠ release artifact має змогу включати: Build — це не без ускладнень “натиснути кнопку”.; Build має змогу включати багато кроків:

Build artifact має змогу бути підписаний.; { </syntaxhighlight> </syntaxhighlight>

SBOM у Build

</syntaxhighlight>

Або:

  • version bump;
  • changelog;
  • tests;
  • security scan;
  • signing;
  • package upload;
  • release notes;
  • artifact storage;
  • deployment approval;
  • tag creation;
  • rollback artifact.; Практична порада: що важливіший програмний продукт, то менше build має залежати від ручних кроків і локальних машин.;== Firmware Build ==

tsc --noEmit Приклад: Build logs доступні для debugging

Incremental build збирає тільки те, що змінилося.; RUN npm run build Output часто зберігається в:

істотно: optimization має спиратися на вимірювання.; істотно: build process має відповідати масштабу проєкту.;
Перевага: build робить програму відтворюваною: команда має змогу знову й знову створювати готовий artifact із контрольованого source code.; * Mobile build має змогу впасти не через код, а через certificate або provisioning profile.; * Практики CI/CD, DevOps, release management і artifact management.;

CI build зазвичай виконує:

Build Warning

Практична роль: DevOps дивиться на build не як на локальну команду, а як на частину шляху від commit до production.; Bundler збирає багато файлів і dependencies у один або кілька optimized bundles.; * У Git source code має змогу бути правильним, але build усе одно має змогу впасти через dependency або environment.;

application uses 3 functions 

"lint": "eslint .",

Frontend Build

COPY .;</syntaxhighlight> переважні аспекти: Приклади: 

pull_request:

Build і Security Scanning

Type checking корисний для:

  • завантажувати тільки потрібний код;
  • прискорити initial load;
  • lazy-load routes;
  • оптимізувати large apps;
  • покращити user experience.; settings chunk
  • C/C++ потрібно компілювати;
  • TypeScript потрібно transpile-ити в JavaScript;
  • React app потрібно bundle-ити;
  • Java потрібно компілювати у bytecode;
  • Android app потрібно зібрати в APK або AAB;
  • Docker app потрібно зібрати в image;
  • static site generator створює HTML/CSS/JS output.;
переважні аспекти:
</div>

== Хороші практики Build ==
== Production Build ==
== Загальний характеристика ==

 "build": "vite build",

release

  • `linux-amd64`;
  • `linux-arm64`;
  • `windows-x64`;
  • `macos-arm64`;
  • `android-release`;
  • `ios-debug`;
  • `web-production`;
  • `server`;
  • `docs`;
  • `test`.; * dependency graph analysis;
  • tree shaking;
  • code splitting;
  • minification;
  • asset processing;
  • CSS extraction;
  • source maps;
  • chunk generation;
  • module resolution.; on:

} 

↓

має змогу включати:

Приклади: Приклади:

Див.; додатково

  • build speed;
  • artifact size;
  • runtime performance;
  • memory usage;
  • dependency size;
  • Docker image size;
  • cache efficiency;
  • parallel execution;
  • test selection;
  • bundle splitting.; Build майже завжди залежить від dependencies.;== Build Performance ==

Приклад спрощено:

Практична роль: цей приклад відокремлює build stage від runtime stage, щоб production image був чистішим.; Приклади:

Code Splitting

Якщо secret потрапив у build:

COPY --from=build /app/dist ./dist

Build Cache

- name: Install dependencies

Run lint

!; * Практики testing, linting, type checking, SBOM, artifact signing, provenance і secure build pipelines.; Frontend artifact не є собою приватним.; Перевірки можуть включати:

Tree shaking видаляє невикористаний code з bundle.;== Build і Linting ==

  • local;
  • remote;
  • CI cache;
  • compiler cache;
  • dependency cache;
  • Docker layer cache;
  • artifact cache.; Для цього потрібні tests.; переважні аспекти:
↓

У CI/CD build запускається автономно.;== Clean Build ==

Практична роль: version — це паспорт build artifact.; Ризики:

  • завантаження dependencies;
  • перевірку версій;
  • компіляцію;
  • transpilation;
  • bundling;
  • linking;
  • minification;
  • tree shaking;
  • generation файлів;
  • копіювання assets;
  • запуск tests;
  • static analysis;
  • security scanning;
  • створення package;
  • створення Docker image;
  • підписування artifact;
  • створення checksum;
  • публікацію artifact у registry.; Якщо secret уже був у artifact, його потрібно замінити.;
  • Astro;
  • Next.js static export;
  • Gatsby;
  • Hugo;
  • Eleventy;
  • Docusaurus;
  • VitePress;
  • MkDocs.; Практична роль: SBOM відповідає на питання: “З чого саме складається цей build?”
  • cross-compilation;
  • hardware-specific flags;
  • linker scripts;
  • memory layout;
  • bootloader integration;
  • binary image generation;
  • checksums;
  • signing;
  • flashing package.;</syntaxhighlight>

Mobile build враховує:

Build Optimization

tsc Build target — конкретний результат або платформа, для якої виконується build.;== Build Number і Version ==

Build і Source Maps

COPY package*.json ./ 

'''Release build''' — збірка для production або офіційного релізу.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== Build Failure ==

RUN npm ci

* debug symbols;
* менш агресивну оптимізацію;
* verbose logs;
* assertions;
* source maps;
* developer-friendly errors;
* hot reload;
* dev server;
* diagnostic tools.; Dependency management охоплює:
Build є собою важливою частиною software supply chain.; !; '''Build time''' — час створення artifact.; * Docker image — це теж build artifact.;== Build Tool ==
'''істотно:''' cross-compilation потребує правильного toolchain, libraries і target configuration.; Приклади:
'''Найлюдяніший факт:''' source code — це рецепт, build process — це кухня, а build artifact — готова страва, яку реально отримує користувач системи.;</div>
== Linker ==

має змогу включати:

  • deprecated API;
  • unused variable;
  • large bundle size;
  • vulnerable dependency;
  • missing source map;
  • type mismatch;
  • unstable feature;
  • peer dependency warning;
  • configuration fallback.; ↓

</syntaxhighlight> Практична роль: debug build створений для розробника, а не для кінцевого користувача.; Linker поєднує compiled object files і libraries у фінальний executable або library.; npm run lint

  • Bazel;
  • Nx;
  • Turborepo;
  • Pants;
  • Buck;
  • Gradle multi-project;
  • pnpm workspaces.; Саме з цієї причини в професійній розробці істотно не лише “код функціонує в мене локально”, а й “чи можна стабільно зібрати той самий результат у CI, протестувати його й доставити в production”.;== Source Code і Build ==
  • `.exe`;
  • `.dll`;
  • `.jar`;
  • `.war`;
  • `.apk`;
  • `.aab`;
  • `.ipa`;
  • `.whl`;
  • `.tar.gz`;
  • Docker image;
  • frontend `dist/`;
  • static site output;
  • compiled CSS;
  • JavaScript bundle;
  • firmware image;
  • release archive;
  • source maps;
  • checksums.;
Критично: видалити secret із наступного build недостатньо.;
  • timestamps;
  • random values;
  • different dependency versions;
  • different OS packages;
  • non-pinned images;
  • network downloads;
  • local machine differences;
  • environment variables;
  • generated files.; * syntax error;
  • failing tests;
  • missing dependency;
  • incompatible version;
  • network error;
  • wrong environment variable;
  • insufficient memory;
  • disk full;
  • permission issue;
  • broken lock file;
  • compiler error;
  • lint error;
  • security scan failure;
  • flaky test;
  • invalid configuration.; .; істотно: warnings не варто ігнорувати місяцями.; Повільний build призводить до:
  • unit tests;
  • integration tests;
  • end-to-end tests;
  • smoke tests;
  • type checks;
  • linting;
  • static analysis;
  • security scans;
  • performance tests.; Краще тестувати той самий artifact, який піде в production.;
     ↓

arm64

</syntaxhighlight>

  • мінімізує assets;
  • вимикає dev warnings;
  • використовує production environment;
  • має optimized output;
  • проходить tests;
  • проходить security scans;
  • має version info;
  • створює deployment artifact;
  • не містить test-only code;
  • не містить secrets.; build/

make

істотно: build, який успішно створив artifact, не гарантує, що програма функціонує правильно.; Критично: якщо build pipeline скомпрометований, attacker має змогу створити “офіційно затверджений” artifact зі шкідливим кодом.;== Build у CI/CD ==

Підписують:

Backend Build

Критично: якщо secret потрапив у frontend build, він стає доступним користувачам.; Практична роль: type checking надає можливість зупинити build ще до runtime-помилки.; * Поганий build process часто стає “усною традицією” команди.; SBOM корисний для:

} 

"scripts": {

Корисні для:

WORKDIR /app Cache має змогу бути: Multi-stage build у Docker надає можливість відокремити build environment від runtime image.; Security scanning має відбуватися до release.; Source code сам по собі не завжди є собою готовою програмою.;

Docker Build

  • хто створив artifact;
  • чи artifact не змінювався;
  • чи можна довіряти release;
  • чи artifact походить із правильного pipeline.; * можуть розкривати source code;
  • можуть містити шляхи файлів;
  • можуть допомогти attackers зрозуміти структуру app;
  • потребують контрольованого доступу в production.; Приклад:

Приклади bundlers: 

Але logs можуть випадково містити sensitive data.; '''Небезпека:''' якщо тільки одна людина знає, як зібрати проєкт, build process уже є собою ризиком для команди.; Build tools
'''істотно:''' реальний production pipeline часто додатково додає caching, security scanning, artifact upload і deployment stages.; '''Build failure''' — ситуація, коли build не завершився успішно.; * Документація Docker build, frontend build systems, backend build tools, mobile build pipelines і cloud CI platforms.; Source code

* Webpack;
* Vite;
* Rollup;
* esbuild;
* Parcel;
* Turbopack у частині сучасних frontend-сценаріїв.; Захист:

Небезпечні приклади:

Це істотно для:

Цікаві факти про Build

  • dependency versions;
  • compiler version;
  • locale;
  • timezone;
  • timestamps;
  • file ordering;
  • random seeds;
  • build paths;
  • environment variables.;=== Mobile app ===

mvn package

Можливі проблеми:

Практична роль: build target надає можливість одному проєкту створювати різні artifacts для різних середовищ і платформ.;
  • optimization;
  • minification;
  • stripped debug symbols у частині сценаріїв;
  • production configuration;
  • security checks;
  • signing;
  • checksums;
  • version metadata;
  • final artifacts;
  • reproducible або traceable output;
  • no development-only flags.; * швидше завантаження;
  • менше traffic;
  • кращий frontend performance.;== Приклади сценаріїв використання ==

</syntaxhighlight> npm run build Release build часто має:

</syntaxhighlight>

Build cache зберігає результати попередніх build-кроків, щоб не виконувати їх повторно.; Frontend build готує web application для браузера.;
</div>
</div>
== Build Metadata ==

</div>
</div>
У DevOps build є собою частиною delivery lifecycle.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

 steps:

'''Практична роль:''' metadata сприяє відповісти на питання: “Що саме зараз запущено?”

'''Практична роль:''' code splitting не змушує користувача завантажувати весь застосунок одразу.; Суть

* знайти помилку;
* зрозуміти failed step;
* побачити versions;
* перевірити warnings;
* audit-ити release;
* debug-ити CI;
* аналізувати performance build-у.; Типовий build-процес:

* README з командою запуску;
* lock file;
* basic tests;
* simple CI;
* versioning;
* clear output.; Приклад:

* embedded systems;
* mobile development;
* IoT;
* server binaries;
* multi-platform CLI tools;
* Docker multi-arch images.; * static linking;
* dynamic linking;
* link-time optimization;
* symbol resolution.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Deploy to test

Configuration drift виникає, коли environments або build machines відрізняються.; * Build once, deploy many зменшує різницю між staging і production.; Це часта причина production-багів.;
run: npm run build

Build Artifact

Практична роль: script `ci` дає одну команду для перевірки, яку можна запускати і локально, і в CI.; Його потрібно проектувати.;== Dependency Management ==

Критично: unsigned artifact легше непомітно підмінити в software supply chain.;=== Go CLI tool ===

Build у Open Source

як ілюстрація:

Build і Runtime

Compiler або компілятор перетворює код однією мовою в іншу форму, часто ближчу до виконання машиною або runtime.; Приклади: Приклад:

переважні аспекти: Build logs допомагають: iOS artifacts:

Monorepo Build

Lint або static analysis запускається .next/

make clean Практична роль: multi-stage build надає можливість будувати в одному середовищі, а запускати в легшому й безпечнішому.;</syntaxhighlight>

  • Make;
  • CMake;
  • Gradle;
  • Maven;
  • Bazel;
  • Ninja;
  • MSBuild;
  • Cargo;
  • npm scripts;
  • pnpm scripts;
  • Yarn scripts;
  • Poetry у Python-сценаріях;
  • setuptools;
  • Hatch;
  • Pants;
  • Buck.;
Deterministic build — build, який за однакових умов завжди дає однаковий результат.;

Приклад:

FROM node:22-alpine AS build

  • є собою production deployment;
  • є собою mobile app release;
  • є собою compiled language;
  • є собою frontend bundle;
  • є собою Docker images;
  • є собою CI/CD;
  • є собою package distribution;
  • є собою security requirements;
  • є собою compliance;
  • є собою open source users;
  • є собою multi-platform support;
  • є собою release artifacts;
  • є собою rollback process.;
Backend build готує server-side application.; * Frontend build має змогу сильно впливати на швидкість сайту через bundle size.;
</div>

COPY package*.json ./

 branches:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

cargo build --release

=== Dockerized service ===

</div>

Build Target

Build matrix — набір варіантів build для різних платформ, версій або конфігурацій.; WORKDIR /app Runtime — час виконання програми.; npm run dev Mobile build створює package для мобільної платформи.; vendor chunk

CI збирає binaries для Linux, macOS і Windows, додає checksums і публікує release.; Dependencies зафіксовані lock file

Але навіть простий проєкт має змогу виграти від:

  • libraries;
  • CLI tools;
  • cross-platform apps;
  • open source projects;
  • compatibility testing;
  • multi-runtime support.; npm run build

<syntaxhighlight lang="text"> staging

істотно: production має запускати перевірений artifact, а не випадковий стан файлів із ноутбука розробника.; * Найкращий build process зазвичай нудний: запускається одна команда, усе проходить, artifact збережено.; це бізнес-процес перетворення source code, assets, dependencies і configuration у готовий результат, який можна запускати, тестувати, розгортати або публікувати виступає ключовою рисою Build або збірка.; Приклади інструментів: RUN npm run build

COPY package*.json ./

development

Отримано з https://wiki.corp2.eu/index.php?title=Build&oldid=1396