Build

Ризики:

'''критично:''' cross-compilation потребує правильного toolchain, libraries і target configuration. '''Build tool''' — конкретний інструмент, який запускає або керує build process. }
</div>

== Build і Security Scanning ==

Build — це не без зусиль “натиснути кнопку”.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* cache invalidation;
* ризик stale output;
* складність dependency graph;
* іноді важче debug. через '''Практична роль:''' build matrix користувачі можуть перевірити, що проєкт функціонує не тільки в одному ідеальному середовищі.=== Dockerized service ===
 "version": "1.4.2",
== Приклад Docker build ==

<syntaxhighlight lang="text">

}

Приклад:

* `1.4.2`;
* `1.4.2+105`;
* `2026.05.09`;
* `git-a1b2c3d`;
* `build-3481`;
* `v2.0.0-rc.1`. '''критично:''' dev build зручний, але він здатна бути повільним, небезпечним або занадто відкритим для production-середовища.== Build Tool ==
CI build зазвичай виконує:
 ↓
'''Критично:''' якщо secret потрапив у frontend build, він стає доступним користувачам. '''критично:''' помилки linking часто з’являються не через синтаксис коду, а через неправильні libraries, symbols або build configuration.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Build здатна включати багато кроків:
Frontend build здатна включати:
Типовий build-процес:

</div>
<syntaxhighlight lang="text">
Mobile build враховує:

</div>

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

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

vendor chunk Приклади інструментів: Lint або static analysis запускається

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

TypeScript;
Java;
C#;
Rust;
Go;
Kotlin;
Scala;
typed Python у частині сценаріїв;
API contracts. Приклади:

Приклади: критично: mobile release build часто залежить не тільки від коду, а й від правильного signing і store metadata.=== Mobile app ===

rm -rf dist node_modules/.cache

"test": "vitest run",

C/C++ потрібно компілювати;
TypeScript потрібно transpile-ити в JavaScript;
React app потрібно bundle-ити;
Java потрібно компілювати у bytecode;
Android app потрібно зібрати в APK або AAB;
Docker app потрібно зібрати в image;
static site generator створює HTML/CSS/JS output.</syntaxhighlight>

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

фабрики: що з чого робити забезпечується через Проста аналогія: build system — це інструкція; так само реалізовано у якому порядку й якими інструментами. Критично: release build має бути зібраний контрольовано, перевірено й збережено як artifact. * base image;

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

↓

Run tests npm run dev

Головна думка: build — це міст між кодом і реальним продуктом.

settings chunk

'''Підказка:''' якщо результат build не можна знайти, перевірити й повторити, build process варто покращити. '''критично:''' deterministic build не виникає випадково. це бізнес-процес перетворення source code, assets, dependencies і configuration у готовий результат, який можна запускати, тестувати, розгортати або публікувати виступає ключовою рисою '''Build''' або '''збірка'''. Приклад:

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

* Документація build tools, compilers, bundlers і package managers.== Multi-Stage Build ==
</div>

Version metadata оптимізує:

Development build — збірка для локальної роботи. Приклади:

Небезпека: якщо тільки одна людина знає, як зібрати проєкт, build process уже виступає як ризиком для команди. Code splitting розбиває application bundle на частини. docker build -t my-app:1.0.0 .

.next/ Хороший build process має бути автоматизованим, повторюваним, контрольованим, безпечним і зрозумілим. здатна включати: npm run build

критично: source maps корисні, але для production потрібно вирішити, чи вони public, private або завантажуються тільки в error monitoring service.

Build artifact здатна бути підписаний. критично: cache має прискорювати build, але не має змінювати його правильність.== Build і Source Maps ==

застосовується для для:

npm run lint

version bump;
changelog;
tests;
security scan;
signing;
package upload;
release notes;
artifact storage;
deployment approval;
tag creation;
rollback artifact. Суть

Хороші практики Build

Критично: видалити secret із наступного build недостатньо.

SBOM корисний для:

Приклади:

"commit": "a1b2c3d",
- name: Run tests

Build особливо важливий, якщо:

Static site build створює готові HTML, CSS і JavaScript файли.

Type checking перевіряє відповідність типів. * security response;

compliance;
vulnerability tracking;
supply chain security;
enterprise audits.== Build Pipeline ==

tsc --noEmit

Source Code і Build

</syntaxhighlight> конкурентні переваги: COPY package*.json ./

Install dependencies

SBOM у Build

</syntaxhighlight>

Критично: build artifact здатна містити вразливі dependencies або secrets. FROM node:22 AS build Недоліки: CI створює Android AAB або iOS archive, підписує build і відправляє в testing channel або app store process. Перевага: build робить програму відтворюваною: команда здатна знову й знову створювати готовий artifact із контрольованого source code. Практична роль: script `ci` дає одну команду для перевірки, яку можна запускати і локально, і в CI. . * Поганий build process часто стає “усною традицією” команди. * Найкращий build process зазвичай нудний: запускається одна команда, усе проходить, artifact збережено. ↓

</syntaxhighlight>

Clean build корисний, коли:

syntax issues;
unused variables;
suspicious code;
formatting problems;
unsafe patterns;
accessibility issues у frontend;
dependency issues у частині інструментів. Етап

завантаження dependencies;
перевірку версій;
компіляцію;
transpilation;
bundling;
linking;
minification;
tree shaking;
generation файлів;
копіювання assets;
запуск tests;
static analysis;
security scanning;
створення package;
створення Docker image;
підписування artifact;
створення checksum;

публікацію artifact у registry. Якщо команда звикає ігнорувати червоний pipeline, pipeline втрачає сенс.

* легше debug;
* швидше розробляти;
* кращі error messages. Linting під час build оптимізує знайти:

Deploy staging

* TypeScript → JavaScript;
* modern JavaScript → older JavaScript;
* JSX → JavaScript;
* Sass → CSS;
* Less → CSS.<syntaxhighlight lang="dockerfile">
== Build у Open Source ==
Build майже завжди залежить від dependencies. Для цього потрібні tests. * TypeScript compilation;
* JSX transformation;
* bundling;
* minification;
* tree shaking;
* CSS processing;
* image optimization;
* font handling;
* code splitting;
* source maps;
* static asset hashing.</div>
</div>
Але навіть простий проєкт здатна виграти від:

Приклади:

== Build і Tests ==

== Висновок ==

* хто створив artifact;
* чи artifact не змінювався;
* чи можна довіряти release;
* чи artifact походить із правильного pipeline. конкурентні переваги:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

== Signing Build Artifact ==
Linking здатна бути:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

 ↓

Приклад:

'''Практична порада:''' build failure — це не без зусиль перешкода.

process HTTP request;
connect to database;
read environment variable;
handle user action;
write logs. Приклад

Firmware Build

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

Debug build часто має: критично: якщо clean build функціонує, а incremental build ні, проблема здатна бути в cache або dependency tracking. В open source build має бути зрозумілим для contributors. * Mobile build здатна впасти не через код, а через certificate або provisioning profile. * environment;

target platform;
compiler flags;
optimization level;
feature flags;
dependency versions;
output path;
debug symbols;
signing keys;
architecture;
runtime;
secrets references;

build arguments. ! * Практики CI/CD, DevOps, release management і artifact management.

Build system здатна:
</div>

 - name: Install dependencies

* libraries;
* CLI tools;
* cross-platform apps;
* open source projects;
* compatibility testing;
* multi-runtime support. '''Cross-compilation''' — збірка програми для платформи, відмінної від платформи, на якій виконується build. Це важливий етап між написанням коду й реальним використанням програми.

Build logs доступні для debugging

`.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. Практична роль: build target дає можливість одному проєкту створювати різні artifacts для різних середовищ і платформ. Він повинен працювати в CI, використовувати lock files, не включати secrets, створювати versioned artifacts і дозволяти команді знати, що саме було зібрано, протестовано й розгорнуто. У Build pipeline часто передбачено security scanning. * package manifests;
lock files;
version constraints;
dependency resolution;
private registries;
vulnerability scanning;
license scanning;
dependency caching;
transitive dependencies. Build cache зберігає результати попередніх build-кроків, щоб не виконувати їх повторно. Security scan виконується

dependency pinning;
secret scanning;
build isolation;
signed artifacts;
provenance;
SBOM;
least privilege CI tokens;
trusted builders;
review of build scripts;

protected branches.

Приклад:

</div>

Production build не містить secrets

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

Головне правило: хороший build має бути автоматичним, повторюваним, перевіреним, зрозумілим і не залежати від магії конкретного комп’ютера. * Практики testing, linting, type checking, SBOM, artifact signing, provenance і secure build pipelines. out/

checkout code;
install dependencies;
lint;
test;
build;
scan;
upload artifacts;
deploy preview;
publish image.== Build і Runtime ==

caching;
incremental builds;
parallelization;
remote cache;
dependency pruning;
test splitting;
faster tools;
smaller modules;
build profiling. Погано:

Minification зменшує розмір JavaScript, CSS або HTML. * push;

pull request;
merge;
tag;
release;
schedule;
manual trigger.== Приклад простого build script ==

Ризики:

↓

Build target — конкретний результат або платформа, для якої виконується build. Firmware build створює software image для embedded devices. Приклад:

зрозуміти, що deployed;
debug-ити bugs;
робити rollback;
зв’язати artifact із commit;
вести release notes;
підтримувати users;
audit-ити production.

Захист: Проста різниця: build створює “що запускати”, deployment визначає “де й як запускати”. * `package-lock.json`;

`pnpm-lock.yaml`;
`yarn.lock`;
`poetry.lock`;
`Cargo.lock`;
`go.sum`;
`Gemfile.lock`. Приклади:

containerized builds;
pinned versions;
lock files;
CI builds;
infrastructure as code;
version managers;

reproducible environments. критично: provenance оптимізує довести, що artifact створено з правильного коду правильним pipeline.

<syntaxhighlight lang="json">

== Cross-Compilation ==

 run: npm test

'''Практична роль:''' reproducible build дає можливість перевірити, що artifact справді відповідає source code, а не випадковим умовам збірки. Підписування оптимізує перевірити:

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

* debug symbols;
* менш агресивну оптимізацію;
* verbose logs;
* assertions;
* source maps;
* developer-friendly errors;
* hot reload;
* dev server;
* diagnostic tools.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* packages;
* versions;
* dependencies;
* licenses;
* hashes;
* supplier info;
* relationships. '''Runtime''' — час виконання програми.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
tsc
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Artifact має version metadata

Практична роль: linting ловить частину проблем до того, як вони потраплять у artifact. ↓

Android artifacts:

build speed;
artifact size;
runtime performance;
memory usage;
dependency size;
Docker image size;
cache efficiency;
parallel execution;
test selection;
bundle splitting.

конкурентні переваги: Build здатна бути простим, якщо: Небезпека: нестабільний build підриває довіру до CI. * debugging;

error tracking;
production stack traces;
frontend monitoring;
QA. Build once, deploy many — практика, де artifact збирають один раз, а потім просувають через environments.

COPY . * source repository;

commit;
branch або tag;
build system;
builder identity;
dependencies;
build time;
build command;
test results;
artifact hash;
signature. Проста різниця: compiler часто веде до lower-level output, а transpiler зазвичай переводить код у схожу або суміжну мову.

unit tests;
integration tests;
end-to-end tests;
smoke tests;
type checks;
linting;
static analysis;
security scans;
performance tests.

Run unit tests

Bundler

mvn package

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

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

критично: build, який успішно створив artifact, не гарантує, що програма функціонує правильно. development

завантажувати тільки потрібний код;
прискорити initial load;
lazy-load routes;
оптимізувати large apps;
покращити user experience.

Pipeline створює Docker image, сканує його, підписує й пушить у container registry.</syntaxhighlight> Інструменти:

Build	Створити artifact	Зібрати Docker image
Deployment	Запустити artifact у середовищі	Розгорнути image у Kubernetes

make clean

↓

Джерела

compile TypeScript;
bundle assets;
generate static pages;
install dependencies;
create image. Dependency management містить:

Build Logs

build/

конкурентні переваги: Типи перевірок:

Build часто має version або build number.

Причини:

цифровізувати 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.</syntaxhighlight>

Tests запускаються Приклади:

</syntaxhighlight>

Build optimization здатна стосуватися:

це маленький script;
немає compilation;
немає dependencies;
це навчальний проєкт;
немає production;
немає release artifact;
достатньо запуску interpreter. Build виступає як центральною частиною software delivery, CI/CD і release management. Приклад:

Clean build — збірка з очищеного стану, без використання старих intermediate files або cache. Release build створюється не вручну

Build time — час створення artifact. * commit SHA;

branch;
build time;
build number;
CI job ID;
compiler version;
dependency versions;
target platform;
artifact checksum;
builder identity;
test status.</syntaxhighlight>

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

Build Optimization

критично: без lock file build здатна сьогодні зібратися з одними dependencies, а завтра — з іншими. public/ SEO title: Build — збірка програмного забезпечення, build process, CI/CD, artifacts, compiler і release

SEO keywords: Build, збірка, software build, build process, build artifact, compiler, transpiler, bundler, linker, build system, build tool, CI/CD, clean build, incremental build, reproducible build, build cache, dependency management, release build, Docker build, frontend build, backend build, DevOps

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

Приклад:

RUN npm run build

критично: production має запускати перевірений artifact, а не випадковий стан файлів із ноутбука розробника. WORKDIR /app

Backend Build

Incremental build збирає тільки те, що змінилося. production

Deterministic Build

Build Configuration

↓

Практична роль: SBOM відповідає на питання: “З чого саме складається цей build?”

Code Splitting

Приклади: У monorepo багато проєктів або packages живуть в одному repository. Build часто пов’язаний із tests. cargo build --release

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

SBOM або Software Bill of Materials здатна створюватися під час build. Він тісно пов’язаний із reproducible build. ERP-платформа

Build у DevOps

Build у Release Management

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

FROM nginx:alpine

Найлюдяніший факт: build — це момент істини: код перестає бути без зусиль набором файлів і стає чимось, що можна реально запустити. * менший final image;

немає build tools у production image;
краща безпека;
чистіший runtime;
швидший deployment. "buildNumber": 3481,

gcc main.c -o app

Ризики:

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.=== Frontend application ===

↓
↓

У Git source code здатна бути правильним, але build усе одно здатна впасти через dependency або environment.== Приклад checklist для Build ==

Compile / Transpile / Bundle

застосовується для в:

Практична роль: incremental build економить час розробника, бо не змушує щоразу збирати весь світ заново. Build application

Build і Configuration Drift

Або:

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

CMD ["node", "dist/server.js"]
== Build і Minification ==

Create artifact

'''Tree shaking''' видаляє невикористаний code з bundle. * Frontend build здатна сильно впливати на швидкість сайту через bundle size. ↓

* довгого feedback loop;
* менш частих tests;
* більших pull requests;
* роздратування команди;
* обходу CI;
* нижчої продуктивності. '''Практична роль:''' type checking дає можливість зупинити build ще до runtime-помилки. staging

* менше різниць між environments;
* artifact уже протестований;
* простіший audit;
* кращий rollback;
* менше “але в staging був інший build”. COPY package*.json ./
Environment variables часто використовуються під час build.</div>

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

* знайти помилку;
* зрозуміти failed step;
* побачити versions;
* перевірити warnings;
* audit-ити release;
* debug-ити CI;
* аналізувати performance build-у. COPY . '''критично:''' optimization має спиратися на вимірювання. Приклад:
</div>
== Linker ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
{| class="wikitable"

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

'''Build pipeline''' — послідовність автоматизованих кроків для створення й перевірки artifact. go build -o server ./cmd/server

 "build": "vite build",

не мати 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. Практична роль: multi-stage build дає можливість будувати в одному середовищі, а запускати в легшому й безпечнішому. run: npm run build

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

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

debug

Dependencies

`.env` у Docker image;
private key у mobile package;
API token у frontend bundle;
password у build log;
cloud credentials у artifact;
secret у source map. Інакше можна прискорити не те, що реально гальмує. * Clean build часто знаходить проблеми, які приховував cache.

Transpiler

OS: linux, windows, macos

Приклад:

== Build і Linting ==
Build artifact once
Scan image
<syntaxhighlight lang="text">
Runtime: node 20, node 22
release
<syntaxhighlight lang="bash">
'''Практична роль:''' build tool автоматизує повторювані кроки, які вручну були б повільними й помилковими. Небезпечно, коли результат залежить від випадкових локальних налаштувань. * C → machine code;
* C++ → machine code;
* Rust → machine code;
* Go → binary;
* Java → bytecode;
* C# → intermediate language;
* Swift → native code. Якщо secret уже був у artifact, його потрібно замінити.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Корисні для:

'''Практична роль:''' frontend build перетворює код розробника на файли, які браузер здатна оперативно завантажити. - main
Run lint

Dependencies зафіксовані lock file

FROM node:22-alpine AS runtime

CI збирає binaries для Linux, macOS і Windows, додає checksums і публікує release.

Docker build створює Docker image з Dockerfile і build context.</syntaxhighlight>

Frontend Build

Clean Build

↓

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

container image scan;
secret scanning;
static application security testing;
license compliance;
SBOM generation;
infrastructure scanning;
malware scanning у частині scenarios. Головна думка: не треба збирати production artifact окремо після testing. Run integration tests

Підписують:

Build виступає як важливою частиною software supply chain.</div>
== Див. так само ==

Bundler здатна робити:
'''Reproducible build''' — build, який із однакового input створює однаковий output. '''Build provenance''' — інформаційні матеріали про походження build artifact. '''Практична роль:''' backend build створює artifact, який можна запустити на сервері або в container. ↓

== Build Performance ==

* hot reload;
* source maps;
* fast rebuild;
* dev server;
* mock data;
* verbose warnings;
* local API endpoints;
* relaxed optimization. * automation;
* repeatability;
* artifact storage;
* traceability;
* CI/CD;
* security scanning;
* deployment promotion;
* rollback;
* environment parity;
* observability;
* release governance.<syntaxhighlight lang="text">
конкурентні переваги:
конкурентні переваги:

<syntaxhighlight lang="text">
Приклади:
Але secrets не варто випадково вшивати в frontend або public artifact.<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

* embedded systems;
* mobile development;
* IoT;
* server binaries;
* multi-platform CLI tools;
* Docker multi-arch images. '''критично:''' реальний production pipeline часто так само додає caching, security scanning, artifact upload і deployment stages.== Build Artifact ==

Upload artifact

* compilation;
* packaging;
* dependency resolution;
* static analysis;
* tests;
* migrations packaging;
* Docker image build;
* configuration validation;
* artifact creation;
* binary generation. виступає як зрозумілий README для build process
'''Практична роль:''' compiler перетворює людський код на форму, яку здатна виконати комп’ютер або runtime. * security;
* audit;
* trust;
* open source;
* supply chain verification;
* debugging;
* release confidence. Не кожному pet project потрібен Bazel, але кожному production-проєкту потрібна повторюваність. pull_request:

'''Практична роль:''' bundler перетворює багато frontend-файлів у формат, який браузер здатна оперативно завантажити й виконати. Security scanning має відбуватися до release. * Матеріали щодо reproducible builds, deterministic builds, build cache, dependency locking і software supply chain security. '''Практична роль:''' DevOps дивиться на build не як на локальну команду, а як на частину шляху від commit до production. Способи покращення:
== Production Build ==

</div>

здатна включати:

'''Практична роль:''' checklist оптимізує перетворити build із випадкового набору команд на надійний бізнес-процес. Вони отримують результат build: застосунок у телефоні, `.exe` файл, сайт у браузері, Docker image на сервері або package у package registry. '''Критично:''' firmware build має бути дуже обережним, бо помилка здатна зробити device непрацездатним або складним для відновлення. Краще тестувати той самий artifact, який піде в production. Build функціонує в CI
 "lint": "eslint .",
</div>

'''Практична порада:''' що важливіший ERP-продукт, то менше build має залежати від ручних кроків і локальних машин. '''критично:''' monorepo без розумного build system здатна стати дуже повільним. Саме тому в професійній розробці критично не лише “код функціонує в мене локально”, а й “чи можна стабільно зібрати той самий результат у CI, протестувати його й доставити в production”.</div>

Build on Linux x64 → output for ARM device

* `linux-amd64`;
* `linux-arm64`;
* `windows-x64`;
* `macos-arm64`;
* `android-release`;
* `ios-debug`;
* `web-production`;
* `server`;
* `docs`;
* `test`. * Build logs можуть бути цінними для debugging, але небезпечними, якщо в них потрапили secrets. * Build once, deploy many зменшує різницю між staging і production.</div>
Mobile build створює package для мобільної платформи. Якщо secret потрапив у build:

* deprecated API;
* unused variable;
* large bundle size;
* vulnerable dependency;
* missing source map;
* type mismatch;
* unstable feature;
* peer dependency warning;
* configuration fallback.<syntaxhighlight lang="bash">
admin chunk
Приклади:
</div>
"без зусиль запусти якось, у мене функціонує."

'''Практична роль:''' pipeline робить build не ручним ритуалом, а повторюваним процесом. '''Практична роль:''' CI build перевіряє, що проєкт збирається не тільки на комп’ютері автора змін, а й у чистому контрольованому середовищі.</div>

</div>

* compromised dependency;
* malicious package;
* poisoned cache;
* tampered artifact;
* stolen signing key;
* leaked CI token;
* unsafe build script;
* untrusted pull request;
* vulnerable base image. '''Build system''' — платформа, яка описує, як саме збирати проєкт. * швидше локально;
* менше CPU;
* менше очікування;
* інтуїтивно для великих проєктів;
* краще developer experience.</div>

* stale cache;
* cache poisoning;
* неправильні cache keys;
* різні результати локально й у CI;
* security risks у shared cache. Production build зазвичай:
library exports 100 functions
== Приклади сценаріїв використання ==

Tests можуть запускатися:

* виступає як дивна помилка;
* cache здатна бути пошкоджений;
* потрібно перевірити reproducibility;
* CI має збирати з нуля;
* release має бути максимально чистим;
* залежності змінилися.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
здатна включати:
Це критично для:

'''Build matrix''' — набір варіантів build для різних платформ, версій або конфігурацій. У DevOps build виступає як частиною delivery lifecycle.== Build Failure ==
SBOM описує:

Release management використовує build для створення офіційної версії продукту.== Build Target ==
main.o + utils.o + library.a → app executable
Build можна повторити на clean environment
У software development build здатна створювати executable file, library, mobile app package, Docker image, frontend bundle, backend artifact, static site, firmware image або release package.</div>

* APK;
* AAB.<syntaxhighlight lang="bash">

* Webpack;
* Vite;
* Rollup;
* esbuild;
* Parcel;
* Turbopack у частині сучасних frontend-сценаріїв.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* timestamps;
* random values;
* different dependency versions;
* different OS packages;
* non-pinned images;
* network downloads;
* local machine differences;
* environment variables;
* generated files.</div>
== Коли Build здатна бути простим ==

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
</div>
'''Практична роль:''' static build створює сайт, який можна розмістити на CDN або static hosting без постійного backend rendering. '''Backend build''' готує server-side application. '''Compiler''' або '''компілятор''' перетворює код однією мовою в іншу форму, часто ближчу до виконання машиною або runtime.== Ризики Build Process ==
</div>

== Compiler ==

Приклади:

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

* різні versions Node.js;
* різні compilers;
* різні OS packages;
* різні environment variables;
* різні dependency registries;
* різні local config files;
* різні Docker base images.<syntaxhighlight lang="dockerfile">
'''Основна ідея:''' build перетворює код і ресурси проєкту на конкретний artifact, який можна перевірити, передати, встановити або запустити.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
 ↓
Добре, якщо виступає як:

Build Cache

Практична роль: minification робить frontend artifact компактнішим для користувача.== Incremental Build == Build performance важливий для developer experience. Deploy або release

!

Transpiler перетворює код з однієї мови або версії мови в іншу мову або іншу версію.== Build і Deployment ==

README з командою запуску;
lock file;
basic tests;
simple CI;
versioning;
clear output. Практична роль: metadata оптимізує відповісти на питання: “Що саме зараз запущено?”

Bazel;
Nx;
Turborepo;
Pants;
Buck;
Gradle multi-project;
pnpm workspaces. здатна містити:

Tree Shaking

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

Але logs можуть випадково містити sensitive data. ↓

Приклад:

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

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

Minification здатна:
'''Frontend build''' готує web application для браузера.</div>

* optimization;
* minification;
* stripped debug symbols у частині сценаріїв;
* production configuration;
* security checks;
* signing;
* checksums;
* version metadata;
* final artifacts;
* reproducible або traceable output;
* no development-only flags. '''критично:''' build configuration має бути явною. Docker build здатна включати:

COPY --from=build /app/dist /usr/share/nginx/html
</div>
== Build Once, Deploy Many ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''Release build''' — збірка для production або офіційного релізу.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* IPA;
* archive;
* signed build. }

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

Приклади runtime дій:
Приклад:
Захист:

Deploy to test

 ↓

'''Build warning''' не завжди зупиняє build, але здатна вказувати на проблему.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Source maps''' допомагають пов’язати minified або bundled code з original source. dotnet publish
Build у monorepo здатна потребувати:
|-
| 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
|}

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
 runs-on: ubuntu-latest
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

 build:

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

== Build і Secrets ==

== Build і Supply Chain Security ==
tree shaking tries to include only needed parts
<syntaxhighlight lang="text">
'''Практична роль:''' швидкий build оптимізує команді частіше перевіряти зміни й менше боятися запускати pipeline. Якщо цей міст хиткий, навіть хороший код здатна не дійти до користувача без проблем.

швидші builds;
менше навантаження;
ефективніші CI pipelines;
зручніше для monorepos. Debug build — збірка для розробки й налагодження. Build logs — записи про те, що відбувалося під час build. * signing certificates;
provisioning profiles;
app version;
build number;
permissions;
native dependencies;
assets;
store requirements;
release channels. Store artifact

Практична порада: якщо build функціонує тільки на одному ноутбуці, це не build process, а локальна традиція. RUN npm ci

критично: build process має відповідати масштабу проєкту.

Перевірки можуть включати:

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.

Проста аналогія: tree shaking — це струсити з дерева сухі гілки, які застосунок не використовує.

Потрібно контролювати:
'''критично:''' не плутайте build-time configuration і runtime configuration.<syntaxhighlight lang="json">
</div>
dist/

Artifact зберігається в repository або registry

конкурентні переваги:

local;
remote;
CI cache;
compiler cache;
dependency cache;
Docker layer cache;
artifact cache.

Найлюдяніший факт: source code — це рецепт, build process — це кухня, а build artifact — готова страва, яку реально отримує користувач системи.

{ CI build здатна стартувати при:

Output часто зберігається в:

Build Warning

README build instructions;
lock files;
supported platforms;
CI status;
clear dependencies;
reproducible commands;
tests;
release process;

troubleshooting section.

Build Docker image
<syntaxhighlight lang="bash">
Source code
'''Головна перевага:''' build process перетворює “у мене функціонує” на “ми можемо це стабільно зібрати й перевірити”.=== Java backend ===
== Build System ==

== Monorepo Build ==

== Static Site Build ==

</div>

'''критично:''' warnings не варто ігнорувати місяцями. Це часта причина production-багів.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
== Debug Build ==

jobs:

критично: build logs потрібні для debugging, але їх не можна перетворювати на місце витоку tokens, passwords або private keys. "ci": "npm run lint && npm run test && npm run build"

static linking;
dynamic linking;
link-time optimization;
symbol resolution. Cache здатна бути:

Цікавий факт

Bundler збирає багато файлів і dependencies у один або кілька optimized bundles.

Практична роль: debug build створений для розробника, а не для кінцевого користувача. Практична роль: production build — це реліз системи, яка має бути швидкою, стабільною й безпечною для користувачів. Configuration drift виникає, коли environments або build machines відрізняються. Приклад:

до build;
під час build;
після build;
на artifact;
у окремому pipeline stage.== Build Metadata ==

критично: release build має бути traceable: команда повинна знати, з якого commit, коли й ким він був створений.== Build у CI/CD == dashboard chunk

Проста думка: build artifact — це те, що залишилося після build і що можна реально використати далі.

↓

</syntaxhighlight>

Build matrix корисна для: Build запускається однією командою

push:

менший bundle;
швидше завантаження;
менше JavaScript для виконання;
кращий frontend performance. Build artifact — результат build process.

Release build здатна включати:

!

Приклад:

dependency graph analysis;
tree shaking;
code splitting;
minification;
asset processing;
CSS extraction;
source maps;
chunk generation;
module resolution. Його потрібно проектувати. arm64

Build configuration визначає, як саме виконувати build. * Docker image — це теж build artifact. * можуть розкривати source code;

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

Приклади lock files:

Docker Build

здатна включати:

Go CLI tool

прибрати пробіли;
скоротити імена;
прибрати comments;
оптимізувати expressions;
зменшити bundle size. Production build — build, оптимізований для реального використання користувачами. {

Make;
CMake;
Gradle;
Maven;
Bazel;
Ninja;
MSBuild;
Cargo;
npm scripts;
pnpm scripts;
Yarn scripts;
Poetry у Python-сценаріях;
setuptools;
Hatch;
Pants;
Buck. .</syntaxhighlight>

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

FROM node:22-alpine AS build WORKDIR /app

Reproducible Build

RUN npm run build

Development Build

Загальний SEO-опис

Build Matrix

</syntaxhighlight> Architecture: x64, arm64

конкурентні переваги Build Process

RUN npm ci

'''Linker''' поєднує compiled object files і libraries у фінальний executable або library. Release build часто має:
Reproducibility ускладнюють:
DevOps звертає увагу на:

main bundle

COPY package*.json ./

* виступає як 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. * documentation sites;
* blogs;
* marketing websites;
* Jamstack;
* frontend apps;
* static exports;
* landing pages. ! Сотні warnings роблять справжню проблему невидимою. * Документація Docker build, frontend build systems, backend build tools, mobile build pipelines і cloud CI platforms. Це сигнал, що pipeline зупинив потенційно погану зміну до release.

Deploy same artifact to staging Приклади за екосистемами: Можливі проблеми:

RUN npm ci --omit=dev Deterministic build — build, який за однакових умов завжди дає однаковий результат. Це дає можливість:

binaries;
packages;
mobile apps;
container images;
firmware;
installers. "scripts": {

Команда запускає `npm run build`, отримує optimized files у `dist/`, завантажує їх на CDN або static hosting. Development build не повинен випадково потрапляти в production. WORKDIR /app

steps:

Критично: якщо build pipeline скомпрометований, attacker здатна створити “офіційний” artifact зі шкідливим кодом. Приклад frontend: як приклад: on:

Приклад:

== Build Provenance ==

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

* dependency versions;
* compiler version;
* locale;
* timezone;
* timestamps;
* file ordering;
* random seeds;
* build paths;
* environment variables. npm run build
'''Build failure''' — ситуація, коли build не завершився успішно. Secrets не повинні потрапляти в build artifact або build logs. name: Build
== Mobile Build ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

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

Користувачі майже ніколи не бачать source code. * швидше завантаження;
* менше traffic;
* кращий frontend performance. '''Практична роль:''' простий build process знижує бар’єр входу для нових contributors. linux-amd64

== Environment Variables у Build ==
! run: npm ci

* Astro;
* Next.js static export;
* Gatsby;
* Hugo;
* Eleventy;
* Docusaurus;
* VitePress;
* MkDocs. Не варто збирати release “на чиємусь ноутбуці”. Основні конкурентні переваги:

 branches:

* cross-compilation;
* hardware-specific flags;
* linker scripts;
* memory layout;
* bootloader integration;
* binary image generation;
* checksums;
* signing;
* flashing package. make

application uses 3 functions
Приклади bundlers:
== Dependency Management ==

'''Multi-stage build''' у Docker дає можливість відокремити build environment від runtime image. source code ≠ release artifact
Недоліки:

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

У CI/CD build запускається автоматизовано. Frontend artifact не виступає як приватним. * dependency graph;

affected builds;
remote caching;
task orchestration;
parallel execution;
package boundaries;
incremental checks;
selective testing.

вважати його скомпрометованим;
rotate secret;
перевірити logs;
перевірити artifacts;
видалити небезпечні copies;
оновити pipeline.

windows-x64

</syntaxhighlight> Deploy same artifact to production

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

Pipeline запускає `mvn package`, створює `.jar`, запускає tests і публікує artifact у repository. - name: Build

Build metadata здатна містити:

Source code сам по собі не завжди виступає як готовою програмою.</syntaxhighlight>

Linting перевіряє стиль, помилки й потенційно небезпечні patterns у коді. - uses: actions/checkout@v4 Практична роль: Docker build пакує application і його runtime-залежності в image, який можна запускати однаково в різних середовищах. Build — це бізнес-процес перетворення source code, dependencies, assets і configuration у готовий artifact. * Reproducible builds важливі для довіри до open source і security-sensitive software. Приклад: Приклади build-time дій: Build і deployment — різні етапи. Build tools

Build Number і Version

Build logs допомагають: