Artifact
Artifact або артефакт — це результат роботи, який створюється, зберігається або передається в процесі розробки, тестування, збірки, доставки чи експлуатації системи. У software engineering артефактом може бути binary file, Docker image, package, test report, log, documentation, design mockup, API specification, machine learning model, build output або будь-який інший матеріальний результат процесу.
Слово artifact часто означає не “щось стародавнє з музею”, а конкретний файл або набір файлів, який має значення для команди, процесу чи системи.
Основна ідея: artifact — це “слідом залишений результат роботи”: те, що можна зберегти, перевірити, передати, розгорнути або використати пізніше.
Цікавий факт
У розробці ПЗ артефакт часто важливіший, ніж здається. Наприклад, команда може написати чудовий код, але production запускає не “код із GitHub”, а конкретний build artifact: container image, binary, package або compiled bundle.
Саме тому сучасний DevOps багато уваги приділяє не лише source code, а й тому, який саме artifact був зібраний, ким, коли, з яких dependencies, з якими тестами, з яким checksum і чи можна довести його походження.
Найлюдяніший факт: artifact — це як готова коробка з продуктом. Код — це рецепт, pipeline — це кухня, а artifact — те, що реально їде до користувача.
Загальний опис
Artifact може бути фінальним або проміжним результатом.
Артефакти зустрічаються в:
- software development;
- DevOps;
- CI/CD;
- testing;
- release management;
- documentation;
- UX/UI design;
- data engineering;
- machine learning;
- cybersecurity;
- project management;
- product management;
- enterprise architecture;
- research;
- build systems;
- package management.
Приклади artifacts:
- compiled binary;
- `.jar`, `.war`, `.dll`, `.exe`;
- npm package;
- Python wheel;
- Docker image;
- Helm chart;
- Terraform plan;
- test report;
- code coverage report;
- log file;
- API specification;
- database migration;
- design mockup;
- architecture diagram;
- ML model file;
- dataset snapshot;
- SBOM;
- release notes.
Перевага: artifacts роблять роботу команди відтворюваною: можна побачити, що саме було створено, протестовано й доставлено.
Software Artifact
Software artifact — будь-який створений у процесі розробки програмний або технічний результат.
До software artifacts належать:
- source code;
- binaries;
- libraries;
- packages;
- container images;
- configuration files;
- scripts;
- database schemas;
- API contracts;
- documentation;
- test data;
- build outputs;
- deployment manifests.
Проста думка: software artifact — це не тільки готова програма. Це будь-який важливий результат, який допомагає створити, перевірити або запустити програму.
Build Artifact
Build artifact — результат процесу збірки.
Приклади build artifacts:
- compiled executable;
- Java `.jar`;
- `.NET` assembly;
- JavaScript bundle;
- CSS bundle;
- mobile app package;
- Docker image;
- generated documentation;
- static site output;
- compiled assets;
- source maps;
- checksum files.
Приклад:
src/ → build process → dist/app.bundle.js
У цьому прикладі `dist/app.bundle.js` є build artifact.
Практична роль: build artifact — це те, що pipeline створює після компіляції, bundling або packaging.
Release Artifact
Release artifact — artifact, який готовий до випуску або deployment.
Release artifacts можуть включати:
- production container image;
- signed binary;
- installer;
- mobile app build;
- package version;
- Helm chart;
- release notes;
- checksum;
- SBOM;
- deployment manifest;
- migration scripts.
Release artifact має бути:
- versioned;
- tested;
- traceable;
- reproducible у бажаному сценарії;
- збережений у repository або registry;
- пов’язаний із commit або tag;
- придатний до deployment або distribution.
Важливо: release artifact має бути саме тим, що тестувалося. Не варто тестувати один build, а в production збирати інший “майже такий самий”.
CI/CD Artifact
У CI/CD артефакт — це файл або результат, який pipeline створює й передає між етапами.
CI/CD artifacts можуть бути:
- build outputs;
- test reports;
- coverage reports;
- logs;
- screenshots;
- compiled binaries;
- Docker images;
- deployment packages;
- static analysis reports;
- security scan reports;
- SBOM;
- Terraform plans.
Приклад pipeline:
Checkout code
Run tests
Build artifact
Scan artifact
Store artifact
Deploy artifact
Практична роль: CI/CD artifact — це “передавальний предмет” між етапами pipeline: зібрали, перевірили, зберегли, розгорнули.
Binary Artifact
Binary artifact — скомпільований файл або пакет, який може виконуватися або використовуватися іншими програмами.
Приклади:
- `.exe`;
- `.dll`;
- `.so`;
- `.dylib`;
- `.jar`;
- `.class`;
- `.wasm`;
- compiled CLI tool;
- mobile app binary;
- firmware image.
Binary artifact важливий, бо він часто є фінальним результатом build process.
Важливо: binary artifact важче перевірити очима, ніж source code, тому для нього важливі signatures, checksums, provenance і trusted build pipeline.
Package Artifact
Package artifact — artifact у форматі package manager.
Приклади:
- npm package;
- Python wheel;
- Maven package;
- NuGet package;
- Ruby gem;
- Go module;
- Debian package;
- RPM package;
- Composer package;
- Cargo crate.
Package artifact зазвичай має:
- name;
- version;
- dependencies;
- metadata;
- license;
- checksum;
- package manifest;
- distribution registry.
Практична роль: package artifact дозволяє іншим проєктам встановлювати й використовувати вашу бібліотеку або інструмент через package manager.
Docker Image як Artifact
Docker image — один із найпоширеніших сучасних release artifacts.
Docker image містить:
- application files;
- runtime;
- dependencies;
- filesystem layers;
- default command;
- metadata;
- environment assumptions;
- labels;
- exposed ports.
Приклад:
docker build -t my-app:1.0.0 .
docker push registry.example.com/my-app:1.0.0
У цьому прикладі `my-app:1.0.0` є container artifact.
Практична роль: Docker image робить deployment більш передбачуваним, бо застосунок і його залежності пакуються разом.
Container Registry
Container registry — сховище для container image artifacts.
Registry може зберігати:
- image tags;
- image digests;
- layers;
- metadata;
- signatures;
- vulnerability scan results;
- SBOM у частині платформ.
Приклади registry:
- Docker Hub;
- GitHub Container Registry;
- GitLab Container Registry;
- Amazon ECR;
- Google Artifact Registry;
- Azure Container Registry;
- Harbor;
- private registry.
Практична роль: registry — це склад артефактів, звідки CI/CD, Kubernetes або production бере конкретні images.
Artifact Repository
Artifact repository — спеціальне сховище для build, package і release artifacts.
Воно може зберігати:
- binaries;
- packages;
- container images;
- Helm charts;
- Maven artifacts;
- npm packages;
- Python wheels;
- NuGet packages;
- release bundles;
- metadata;
- checksums.
Artifact repository допомагає:
- версіонувати artifacts;
- контролювати доступ;
- зберігати історію релізів;
- кешувати dependencies;
- підтримувати supply chain security;
- робити rollback;
- відтворювати releases.
Проста аналогія: artifact repository — це бібліотека готових збірок, а не випадкова папка Downloads на ноутбуці розробника.
Versioning
Артефакти мають бути версіоновані.
Поширені підходи:
- semantic versioning;
- build number;
- Git commit SHA;
- date-based version;
- release tag;
- image digest;
- package version;
- environment-specific label.
Приклади:
my-app:1.4.2
my-app:2026.05.09
my-app:git-a1b2c3d
library-2.8.0.jar
Важливо: artifact без версії важко відтворити, перевірити й відкотити.
Checksums
Checksum — коротке значення, яке допомагає перевірити цілісність artifact.
Приклади checksum algorithms:
- SHA-256;
- SHA-512;
- SHA-1 у старіших системах;
- MD5 у legacy-сценаріях, але не для сучасної безпеки.
Checksum допомагає зрозуміти:
- чи artifact не пошкодився;
- чи файл той самий;
- чи download завершився коректно;
- чи artifact відповідає очікуваному digest.
Практична роль: checksum — це як відбиток пальця artifact: якщо вміст зміниться, checksum теж зміниться.
Signing
Signing або підпис artifact допомагає перевірити його походження й цілісність.
Підписування важливе для:
- binaries;
- packages;
- container images;
- mobile apps;
- firmware;
- release archives;
- enterprise software;
- open source distribution.
Signing відповідає на питання:
- хто створив artifact;
- чи змінювався artifact після підпису;
- чи можна довіряти джерелу;
- чи artifact походить із правильного pipeline.
Критично: якщо artifact можна непомітно підмінити, безпека всього release process під загрозою.
Provenance
Provenance — інформація про походження artifact.
Provenance може містити:
- source repository;
- commit SHA;
- branch або tag;
- build system;
- build time;
- builder identity;
- dependencies;
- build parameters;
- test status;
- signatures;
- environment details.
Важливо: provenance допомагає відповісти на питання: “Звідки взявся цей artifact і чи можна йому довіряти?”
SBOM
SBOM або Software Bill of Materials — список компонентів, з яких складається software artifact.
SBOM може містити:
- packages;
- libraries;
- versions;
- licenses;
- dependency relationships;
- hashes;
- supplier information;
- vulnerability context.
SBOM корисний для:
- security;
- license compliance;
- audits;
- vulnerability response;
- supply chain management;
- enterprise governance;
- incident response.
Практична роль: якщо завтра знайдуть вразливість у бібліотеці, SBOM допоможе швидко зрозуміти, які artifacts її містять.
Test Artifact
Test artifact — результат тестування.
Приклади:
- unit test report;
- integration test report;
- end-to-end screenshots;
- code coverage report;
- performance test output;
- QA checklist;
- test logs;
- failed test snapshots;
- browser traces;
- video recording of test run.
Test artifacts допомагають:
- аналізувати помилки;
- підтверджувати якість;
- перевіряти regressions;
- документувати release readiness;
- знаходити flaky tests;
- проводити audit.
Практична роль: test artifact — це доказ того, що перевірка справді виконувалася, а не просто “в нас усе має працювати”.
Log Artifact
Log artifact — файл або набір логів, збережених після запуску, тесту, build або incident.
Log artifacts можуть бути:
- build logs;
- test logs;
- application logs;
- deployment logs;
- security logs;
- audit logs;
- container logs;
- CI job logs.
Вони потрібні для:
- debugging;
- incident analysis;
- audit;
- troubleshooting;
- performance analysis;
- compliance;
- root cause analysis.
Важливо: logs як artifacts мають бути корисними, але не повинні містити passwords, tokens або зайві персональні дані.
Documentation Artifact
Documentation artifact — документ або матеріал, який описує систему, рішення, процес або продукт.
Приклади:
- README;
- API documentation;
- architecture diagram;
- ADR;
- user guide;
- runbook;
- onboarding guide;
- release notes;
- changelog;
- security policy;
- design specification;
- troubleshooting guide.
Практична роль: documentation artifact зберігає знання команди, щоб вони не жили тільки в головах кількох людей.
Design Artifact
Design artifact — результат UX/UI, product design або visual design роботи.
Приклади:
- wireframe;
- mockup;
- prototype;
- user flow;
- journey map;
- design system component;
- style guide;
- persona;
- usability test report;
- information architecture;
- Figma file;
- accessibility notes.
Design artifacts допомагають:
- узгодити очікування;
- перевірити ідею до розробки;
- пояснити user flow;
- зменшити переробки;
- передати дизайн розробникам;
- документувати продуктове рішення.
Цікавий факт: wireframe — це теж artifact, хоча він не запускається як програма. Він фіксує рішення про майбутню взаємодію користувача із системою.
Architecture Artifact
Architecture artifact — матеріал, який описує архітектуру системи.
Приклади:
- architecture diagram;
- C4 diagram;
- sequence diagram;
- deployment diagram;
- data flow diagram;
- ADR;
- threat model;
- integration map;
- infrastructure diagram;
- service catalog;
- dependency map.
Architecture artifacts корисні для:
- onboarding;
- architecture review;
- security review;
- incident analysis;
- planning;
- communication with stakeholders;
- migration;
- compliance.
Важливо: architecture artifact має бути актуальним. Стара діаграма може вводити команду в оману.
ML Artifact
У machine learning ML artifact — це результат навчання, оцінки або deployment моделі.
Приклади:
- trained model file;
- model weights;
- tokenizer;
- dataset snapshot;
- feature schema;
- evaluation report;
- metrics;
- confusion matrix;
- training logs;
- hyperparameters;
- experiment metadata;
- model card;
- inference container image.
ML artifacts особливо важливі, бо модель без metadata часто важко відтворити.
Практична роль: ML artifact — це не тільки файл моделі. Це ще й контекст: на яких даних, з якими параметрами й з якою якістю модель була створена.
Data Artifact
Data artifact — результат роботи з даними.
Приклади:
- dataset;
- data snapshot;
- cleaned CSV;
- Parquet file;
- report;
- dashboard export;
- data quality report;
- feature set;
- anonymized dataset;
- data schema;
- migration output.
Data artifacts важливі для:
- analytics;
- reproducibility;
- ML;
- audit;
- reporting;
- data pipelines;
- compliance;
- debugging.
Важливо: data artifact може містити приватні або чутливі дані, тому для нього потрібні access control, retention і privacy rules.
Project Management Artifact
У project management artifact — це документ або результат, який допомагає керувати роботою.
Приклади:
- roadmap;
- backlog;
- sprint plan;
- user story;
- acceptance criteria;
- risk register;
- status report;
- project charter;
- decision log;
- retrospective notes;
- release plan;
- stakeholder map.
Практична роль: project artifact допомагає команді пам’ятати не тільки що робити, а й чому це робиться.
Artifact у GitHub Actions
У CI-системах на кшталт GitHub Actions artifact часто означає файл, який workflow зберігає після job.
Приклади:
- test results;
- coverage;
- built app;
- screenshots;
- compiled package;
- logs;
- deployment bundle.
Типовий сценарій:
Run tests → Generate report → Upload artifact → Download artifact later
Практична роль: CI artifact дозволяє не втратити результат job після завершення pipeline.
Artifact у GitLab CI
У GitLab CI artifacts використовують для збереження файлів між jobs або після pipeline.
Приклади:
- compiled app;
- test report;
- coverage report;
- static site output;
- build directory;
- deployment package.
Artifact може мати retention time, тобто зберігатися обмежений час.
Важливо: не всі CI artifacts потрібно зберігати вічно. Для logs і temporary reports часто достатньо короткого retention.
Artifact і Dependency
Artifact і dependency пов’язані, але не одне й те саме.
| Поняття | Суть | Приклад |
|---|---|---|
| Artifact | Результат створення або збірки | `my-app:1.0.0` Docker image |
| Dependency | Те, від чого залежить artifact або код | `express`, `react`, `postgres-driver` |
Один artifact може сам стати dependency для іншого проєкту.
Практична роль: бібліотека як package artifact може бути dependency для застосунку.
Artifact і Source Code
Source code теж може бути artifact, але в DevOps зазвичай розрізняють:
- source artifact — код або archive source;
- build artifact — результат збірки;
- release artifact — те, що випускають;
- deployment artifact — те, що розгортають.
Приклад:
Source code → Build artifact → Release artifact → Deployed artifact
Важливо: production має бути прив’язаний до конкретного artifact, а не до нечіткого “останнього коду на main”.
Artifact і Environment
Один artifact може розгортатися в різні environments:
- development;
- testing;
- staging;
- production;
- preview;
- disaster recovery.
Хороша практика:
Build once, deploy many
Це означає, що artifact збирають один раз, а потім просувають через environments із різними конфігураціями.
Практична роль: якщо один і той самий artifact проходить staging і production, команда менше ризикує отримати “у staging працювало, бо build був інший”.
Artifact Retention
Artifact retention — політика зберігання artifacts.
Потрібно вирішити:
- які artifacts зберігати;
- як довго;
- де;
- хто має доступ;
- які artifacts критичні для rollback;
- які можна видаляти;
- чи потрібне legal retention;
- чи містять artifacts чутливі дані;
- скільки коштує storage.
Приклади retention:
- test logs — 7 або 30 днів;
- release artifacts — кілька років;
- security reports — згідно з compliance;
- temporary build outputs — короткий термін;
- production images — до завершення підтримки версії.
Важливо: зберігати все вічно дорого й ризиковано, але видалити release artifact занадто рано може зламати rollback або audit.
Artifact Security
Artifact security — захист artifacts від підміни, витоку й небезпечного використання.
Потрібно контролювати:
- access control;
- signing;
- checksums;
- vulnerability scanning;
- secret scanning;
- license scanning;
- provenance;
- SBOM;
- immutable storage;
- audit logs;
- retention;
- dependency policies;
- trusted builders;
- registry permissions.
Критично: artifact може бути атакований у supply chain. Якщо зловмисник підмінив package або image, production може запустити шкідливий код навіть без зміни source repository.
Artifact у Software Supply Chain
У software supply chain artifact проходить шлях від source code до production.
Типовий ланцюг:
Source code
Dependencies
Build system
Artifact
Artifact repository
Security scan
Release approval
Deployment
Runtime monitoring
Supply chain security вимагає знати:
- хто створив artifact;
- з якого коду;
- з якими dependencies;
- чи проходив тести;
- чи був підписаний;
- де зберігався;
- хто мав доступ;
- який artifact реально запущений.
Практична роль: software supply chain дивиться на artifact як на ланку між розробкою й користувачем.
Immutable Artifact
Immutable artifact — artifact, який після створення не змінюється.
Наприклад, image з digest:
my-app@sha256:abc123...
Immutable artifacts корисні для:
- reproducibility;
- rollback;
- audit;
- security;
- deployment confidence;
- debugging;
- traceability.
Практична роль: immutable artifact дозволяє бути впевненим, що “версія 1.2.3” сьогодні й завтра означає той самий вміст.
Mutable Tags
Mutable tag — тег, який може вказувати на різний вміст у різний час.
Приклад:
latest
dev
staging
main
Це зручно для development, але ризиковано для production.
Важливо: `latest` — не версія, а рухома мітка. Для production краще використовувати конкретну версію або digest.
Artifact і Rollback
Rollback часто залежить від наявності попереднього artifact.
Для rollback потрібно:
- зберегти попередню версію;
- знати, який artifact був deployed;
- мати compatible database state;
- мати rollback plan;
- мати доступ до registry;
- мати deployment automation;
- мати logs і monitoring.
Критично: якщо старий artifact видалили, rollback може перетворитися на emergency rebuild, а це ризиковано.
Artifact і Reproducible Build
Reproducible build — процес, у якому з однакового source code і однакових умов можна отримати той самий artifact.
Це важливо для:
- security;
- trust;
- open source;
- audit;
- deterministic releases;
- supply chain verification;
- debugging.
Reproducible builds ускладнюються через:
- timestamps;
- random values;
- різні dependency versions;
- різні OS packages;
- network downloads;
- build environment differences.
Важливо: reproducible build — це високий рівень дисципліни. Не кожен проєкт його має, але для security-sensitive software це дуже цінно.
Artifact і Configuration
Artifact і configuration краще розділяти.
Приклад хорошої ідеї:
Один artifact
Різні environment variables для dev/staging/prod
Погана практика:
Збирати окремий artifact для production із hardcoded секретами
Configuration може містити:
- database URL;
- feature flags;
- API endpoints;
- environment name;
- log level;
- external service settings.
Практична порада: artifact має бути однаковим, а environment-specific поведінка має керуватися конфігурацією, не секретами всередині build.
Artifact і Secrets
Secrets не повинні потрапляти в artifacts.
Небезпечні приклади:
- `.env` у Docker image;
- private key у package;
- access token у build logs;
- password у test report;
- credentials у static bundle;
- API key у mobile app без захисту;
- secrets у source maps.
Критично: якщо secret потрапив в artifact, його потрібно вважати скомпрометованим і rotate, а не просто видалити файл у наступному build.
Artifact і Compliance
У regulated або enterprise-середовищах artifacts важливі для compliance.
Можуть вимагатися:
- signed artifacts;
- audit logs;
- SBOM;
- license reports;
- vulnerability scan results;
- approval records;
- release notes;
- test evidence;
- provenance;
- retention policy;
- access control;
- change management records.
Практична роль: compliance часто потребує не лише “ми випустили версію”, а доказів: що саме, коли, ким, як перевірено й із яких компонентів.
Artifact у Design Thinking
У design thinking artifact може бути результатом дослідження або дизайну.
Приклади:
- empathy map;
- persona;
- user journey map;
- problem statement;
- prototype;
- wireframe;
- usability report;
- workshop board;
- decision matrix.
Такі artifacts допомагають команді думати спільно й не втрачати контекст користувача.
Найлюдяніший факт: не кожен artifact має бути кодом. Іноді найцінніший artifact — це проста схема, яка нарешті пояснила команді, що болить користувачу.
Artifact у Research
У research artifact — це результат дослідження або експерименту.
Приклади:
- dataset;
- notebook;
- experiment log;
- paper draft;
- chart;
- model output;
- benchmark result;
- survey data;
- transcript;
- analysis report;
- replication package.
Research artifacts важливі для:
- reproducibility;
- peer review;
- validation;
- knowledge transfer;
- future research;
- transparency.
Практична роль: research artifact дозволяє не лише сказати “ми отримали результат”, а й показати, як саме його отримали.
Artifact у Cybersecurity
У cybersecurity artifact може означати файл, доказ або слід, знайдений під час аналізу.
Приклади:
- suspicious binary;
- log file;
- packet capture;
- memory dump;
- malware sample;
- IOC list;
- forensic image;
- audit event;
- incident timeline;
- hash;
- screenshot;
- YARA rule.
Важливо: security artifacts можуть бути чутливими або небезпечними, тому їх потрібно зберігати з контролем доступу й обережністю.
Artifact у Game Development
У game development artifact може бути asset або build output.
Приклади:
- game build;
- texture;
- 3D model;
- animation;
- sound effect;
- level file;
- shader;
- localization file;
- crash dump;
- performance capture;
- save file sample.
Практична роль: у game development artifacts часто включають не тільки код, а й велику кількість творчих assets.
Artifact і Asset
Artifact і asset іноді перетинаються.
| Поняття | Суть | Приклад |
|---|---|---|
| Artifact | Результат процесу або роботи | Build output, test report, release package |
| Asset | Ресурс, який використовується продуктом | Image, icon, sound, 3D model |
Один файл може бути і asset, і artifact. Наприклад, згенерований sprite sheet є asset для гри й artifact build-процесу.
Важливо: artifact більше підкреслює походження з процесу, а asset — корисність як ресурс.
Artifact і Deliverable
Deliverable — те, що команда обіцяє передати замовнику або stakeholder-у.
Artifact може бути deliverable, але не завжди.
| Поняття | Суть | Приклад |
|---|---|---|
| Artifact | Будь-який результат роботи | Test log, build file, prototype |
| Deliverable | Результат, який офіційно передають | Release build, final report, design package |
Проста різниця: artifact може бути внутрішнім, а deliverable зазвичай має зовнішнє або контрактне значення.
Artifact Lifecycle
Artifact має життєвий цикл.
Типові етапи:
- creation;
- validation;
- storage;
- scanning;
- approval;
- promotion;
- deployment;
- monitoring;
- rollback use;
- archival;
- deletion.
Практична роль: artifact lifecycle допомагає керувати не тільки створенням, а й зберіганням, використанням і видаленням artifacts.
Переваги artifacts
Основні переваги artifacts:
- відтворюваність;
- traceability;
- простіший deployment;
- кращий rollback;
- evidence для testing;
- release discipline;
- auditability;
- supply chain security;
- можливість перевірки;
- зручне зберігання;
- командна передача результатів;
- automation;
- контроль версій;
- separation between build and deploy.
Головна перевага: artifact робить результат роботи конкретним: його можна назвати, зберегти, перевірити й використати.
Ризики artifacts
Artifacts мають ризики.
Можливі проблеми:
- artifact без версії;
- artifact із secrets;
- підміна artifact;
- outdated artifact;
- відсутність provenance;
- нестача storage;
- занадто довге retention;
- занадто коротке retention;
- незрозумілий naming;
- release artifact не збігається із протестованим artifact;
- відсутність checksum;
- artifact repository без access control;
- dependency confusion;
- вразливі packages;
- license compliance problems.
Небезпека: погано керовані artifacts можуть перетворити CI/CD із системи довіри на систему випадкових файлів.
Коли artifact особливо важливий
Artifact особливо важливий, якщо:
- є production deployment;
- потрібен rollback;
- система regulated;
- продукт має багато environments;
- є CI/CD;
- використовується Docker або Kubernetes;
- є packages для клієнтів;
- потрібна supply chain security;
- команда велика;
- потрібен audit;
- релізи мають підписуватися;
- ML-моделі потрібно відтворювати;
- потрібно довести, що саме було протестовано.
Практична порада: що важливіший продукт, то важливіше знати не тільки “який код”, а й “який artifact” працює в production.
Коли artifacts можна спростити
Не кожен маленький проєкт потребує складної artifact platform.
Спрощення доречне, якщо:
- це навчальний проєкт;
- немає production;
- немає external releases;
- немає compliance;
- build artifacts легко відтворити;
- команда маленька;
- artifacts тимчасові;
- немає чутливих даних.
Але навіть у малому проєкті корисно мати:
- зрозумілі назви;
- версію;
- README;
- простий release archive;
- backup важливих результатів.
Важливо: artifact management має відповідати ризику й масштабу. Для pet project і банківської системи рівень контролю має бути різним.
Хороші практики artifacts
Рекомендовано:
- версіонувати artifacts;
- зберігати release artifacts у repository або registry;
- використовувати checksums;
- підписувати критичні artifacts;
- не включати secrets;
- сканувати artifacts на vulnerabilities;
- генерувати SBOM для важливих релізів;
- зберігати provenance;
- використовувати immutable references;
- не використовувати `latest` для production без контролю;
- зберігати test reports;
- налаштувати retention policy;
- контролювати доступ;
- документувати release process;
- будувати artifact один раз і просувати через environments;
- мати rollback artifacts.
Головне правило: хороший artifact має бути зрозумілим, перевіреним, версіонованим, захищеним і пов’язаним із джерелом свого походження.
Типові помилки початківців
Поширені помилки:
- називати файл `final-final-v3.zip`;
- не зберігати build output після CI;
- збирати artifact прямо на production-сервері;
- не знати, який commit відповідає artifact;
- використовувати `latest` у production;
- зберігати secrets у artifact;
- не мати checksum;
- не мати rollback artifact;
- видаляти старі release artifacts занадто рано;
- не зберігати test reports;
- не сканувати container images;
- не контролювати доступ до registry;
- вручну копіювати artifact через месенджер;
- не документувати release notes;
- плутати source code, build artifact і deployed artifact.
Небезпека: якщо команда не знає, який artifact зараз у production, incident response стає набагато складнішим.
Цікаві факти про Artifact
- Artifact у DevOps часто означає саме те, що реально deploy-иться, а не просто source code.
- Docker image — один із найпопулярніших сучасних software artifacts.
- Test report — теж artifact, хоча він не є програмою.
- Design mockup може бути artifact так само, як binary file.
- ML model без metadata — слабкий artifact, бо його важко відтворити й оцінити.
- Artifact repository — важлива частина software supply chain.
- `latest` — зручний tag, але поганий спосіб описати release artifact у production.
- Хороший artifact може пережити людей у команді: через роки він пояснить, що саме було випущено.
- Artifact без provenance — як посилка без зворотної адреси.
- У зрілих командах release artifact часто має більше доказів навколо себе: tests, SBOM, signatures, changelog і deployment history.
Найлюдяніший факт: artifact — це спосіб не покладатися на пам’ять людей. Він каже: “Ось конкретний результат. Ось його версія. Ось звідки він узявся”.
Приклади сценаріїв використання
Web application release
Команда збирає frontend bundle, backend Docker image, database migration scripts і release notes. Усі ці файли є artifacts релізу.
Mobile application
CI створює Android APK або AAB, iOS build, test reports і screenshots. Це artifacts, які проходять перевірку перед публікацією.
Java library
Build pipeline створює `.jar`, генерує documentation, підписує package і публікує його в Maven repository.
Machine learning model
Training pipeline створює model weights, tokenizer, evaluation report, metrics, dataset version і model card.
Security incident
Команда зберігає suspicious logs, packet capture, timeline, hashes і forensic notes як security artifacts для розслідування.
Підказка: якщо файл допомагає зрозуміти, перевірити або повторити результат роботи, він майже точно є artifact.
Приклад структури release artifacts
release-1.4.2/
app-image-digest.txt
backend-1.4.2.tar.gz
frontend-dist.zip
migrations/
001_add_invoice_table.sql
sbom.json
checksums.txt
test-report.xml
coverage-report.html
release-notes.md
provenance.json
Практична роль: така структура показує не тільки сам build, а й докази якості, походження й готовності до релізу.
Приклад artifact naming
Погано:
app.zip
new-build.zip
final.zip
final2.zip
latest-prod-real.zip
Краще:
orders-api-1.8.0-linux-amd64.tar.gz
orders-api-1.8.0-sbom.json
orders-api-1.8.0-checksums.txt
orders-api-1.8.0-test-report.xml
Важливо: назва artifact має допомагати зрозуміти, що це, яка версія, для чого й для якої платформи.
Приклад checklist для release artifact
Artifact має версію
Artifact пов’язаний із Git commit або tag
Tests пройшли
Security scan виконано
SBOM створено для важливого релізу
Checksum створено
Artifact підписано, якщо потрібно
Secrets не включені
Release notes готові
Artifact збережено в repository або registry
Rollback artifact доступний
Retention policy визначена
Доступ до artifact обмежений
Практична роль: checklist допомагає не перетворити реліз на “ми десь зібрали якийсь файл”.
Джерела
- Практики software engineering щодо software artifacts.
- Документація CI/CD систем щодо build artifacts і job artifacts.
- Матеріали DevOps щодо release management, artifact repositories і deployment pipelines.
- Практики software supply chain security, SBOM, provenance, signing і checksum verification.
- Документація container registries, package registries і artifact repositories.
- Матеріали щодо ML artifacts, data artifacts, design artifacts, architecture documentation і project management deliverables.
Висновок
Artifact — це конкретний результат роботи: файл, пакет, image, звіт, модель, документація, дизайн, лог або інший матеріал, який створюється в процесі розробки, тестування, збірки, релізу чи дослідження. У software development artifacts допомагають зробити процес відтворюваним, перевірним і керованим.
Найважливіші artifacts у сучасному DevOps — це build artifacts, release artifacts, container images, packages, test reports, SBOM, provenance і documentation. Правильне керування artifacts допомагає з deployment, rollback, audit, security, compliance і командною передачею знань. Погано керовані artifacts створюють ризики: підміна, secrets у build, незрозумілі версії, неможливість rollback і хаос у release process.
Головна думка: artifact — це не просто файл. Це зафіксований результат процесу, якому команда має вміти довіряти.
Див. також
- Software Artifact
- Build Artifact
- Release Artifact
- CI/CD
- DevOps
- Docker Image
- Container Registry
- Artifact Repository
- Package Manager
- Binary
- SBOM
- Software Supply Chain
- Provenance
- Checksum
- Digital Signature
- Testing
- Test Report
- Documentation
- Design Artifact
- Machine Learning
- ML Model
- Data Pipeline
- Release Management
- Deployment
- Rollback
- Безпека застосунків
- Документація
Тематичні мітки
- Artifact
- Артефакт
- Software Artifact
- Build Artifact
- Release Artifact
- CI/CD Artifact
- DevOps Artifact
- Binary Artifact
- Package
- Docker Image
- Container Image
- Test Report
- Log Artifact
- Documentation Artifact
- Design Artifact
- ML Artifact
- Model Artifact
- Artifact Repository
- Artifact Registry
- SBOM
- Provenance
- Software Supply Chain
- Документація