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

Artifact

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

</syntaxhighlight>

Provenance здатна містити:

Приклади checksum algorithms:

Artifact і configuration краще розділяти. Суть |- | Artifact | Результат створення або збірки | `my-app:1.0.0` Docker image |- | Dependency | Те, від чого залежить artifact або код | `express`, `react`, `postgres-driver` |}

!

  • SHA-256;
  • SHA-512;
  • SHA-1 у старіших системах;
  • MD5 у legacy-сценаріях, але не для сучасної безпеки. У cybersecurity artifact здатна означати файл, доказ або слід, знайдений під час аналізу. Практична роль: якщо завтра знайдуть вразливість у бібліотеці, SBOM допоможе оперативно зрозуміти, які artifacts її містять. Поняття

Release notes готові

Mobile application

У design thinking artifact здатна бути результатом дослідження або дизайну. Потрібно вирішити:

my-app@sha256:abc123...
Artifact і asset іноді перетинаються. Run tests → Generate report → Upload artifact → Download artifact later

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

* game build;
* texture;
* 3D model;
* animation;
* sound effect;
* level file;
* shader;
* localization file;
* crash dump;
* performance capture;
* save file sample. release-1.4.2/
Артефакти зустрічаються в:
'''критично:''' зберігати все вічно дорого й ризиковано, але видалити release artifact занадто рано здатна зламати rollback або audit. * Матеріали щодо ML artifacts, data artifacts, design artifacts, architecture documentation і project management deliverables. docker push registry.example.com/my-app:1.0.0
Mutable tag — тег, який здатна вказувати на різний вміст у різний час. Команда зберігає suspicious logs, packet capture, timeline, hashes і forensic notes як security artifacts для розслідування.== Immutable Artifact ==

Runtime monitoring
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''критично:''' release artifact має бути саме тим, що тестувалося.== Log Artifact ==
Source code
== Artifact у GitLab CI ==

== Artifact і Compliance ==

</div>

'''Artifact retention''' — політика зберігання artifacts. Signing відповідає на питання:

* versioned;
* tested;
* traceable;
* reproducible у бажаному сценарії;
* збережений у repository або registry;
* пов’язаний із commit або tag;
* придатний до deployment або distribution. Supply chain security вимагає знати:
Immutable artifacts корисні для:
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

! Правильне керування artifacts оптимізує з deployment, rollback, audit, security, compliance і командною передачею знань. У game development artifact здатна бути asset або build output. Приклад

== Artifact Repository ==

* production container image;
* signed binary;
* installer;
* mobile app build;
* package version;
* Helm chart;
* release notes;
* checksum;
* SBOM;
* deployment manifest;
* migration scripts. Source code → Build artifact → Release artifact → Deployed artifact
</div>

 release-notes.md

== Binary Artifact ==

Приклад:

* packages;
* libraries;
* versions;
* licenses;
* dependency relationships;
* hashes;
* supplier information;
* vulnerability context.== Artifact у Cybersecurity ==

* аналізувати помилки;
* підтверджувати якість;
* перевіряти regressions;
* документувати release readiness;
* знаходити flaky tests;
* проводити audit. Іноді найцінніший artifact — це проста схема, яка нарешті пояснила команді, що болить користувачу. * binaries;
* packages;
* container images;
* Helm charts;
* Maven artifacts;
* npm packages;
* Python wheels;
* NuGet packages;
* release bundles;
* metadata;
* checksums.

критично: production має бути прив’язаний до конкретного artifact, а не до нечіткого “останнього коду на main”. Воно здатна зберігати:

Documentation Artifact

У GitLab CI artifacts використовують для збереження файлів між jobs або після pipeline. Різні environment variables для dev/staging/prod

  • Docker Hub;
  • GitHub Container Registry;
  • GitLab Container Registry;
  • Amazon ECR;
  • Google Artifact Registry;
  • Azure Container Registry;
  • Harbor;
  • private registry. src/ → build process → dist/app.bundle.js
  • README;
  • API documentation;
  • architecture diagram;
  • ADR;
  • user guide;
  • runbook;
  • onboarding guide;
  • release notes;
  • changelog;
  • security policy;
  • design specification;
  • troubleshooting guide. Практична роль: test artifact — це доказ того, що перевірка справді виконувалася, а не без зусиль “в нас усе має працювати”. * Документація container registries, package registries і artifact repositories. Source code теж здатна бути artifact, але в DevOps зазвичай розрізняють:

Artifact Lifecycle

  • Практики software engineering щодо software artifacts. У software engineering артефактом здатна бути binary file, Docker image, package, test report, log, documentation, design mockup, API specification, machine learning model, build output або будь-який інший матеріальний результат процесу. Приклади:

</syntaxhighlight> критично: reproducible build — це високий рівень дисципліни. * 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. * roadmap;
  • backlog;
  • sprint plan;
  • user story;
  • acceptance criteria;
  • risk register;
  • status report;
  • project charter;
  • decision log;
  • retrospective notes;
  • release plan;
  • stakeholder map.</syntaxhighlight>

критично: не всі CI artifacts потрібно зберігати вічно. * У зрілих командах release artifact часто має більше доказів навколо себе: tests, SBOM, signatures, changelog і deployment history. Це будь-який важливий результат, який користувачі можуть створити, перевірити або запустити програму. latest

Приклади:

CI/CD Artifact

критично: data artifact здатна містити приватні або чутливі інформаційні дані, тому для нього потрібні access control, retention і privacy rules. Це ще й контекст: на яких даних, з якими параметрами й з якою якістю модель була розроблена. Практична роль: checksum — це як відбиток пальця artifact: якщо вміст зміниться, checksum теж зміниться. Це означає, що artifact збирають один раз, а потім просувають через environments із різними конфігураціями.

my-app:1.4.2

критично: artifact management має відповідати ризику й масштабу. app-image-digest.txt orders-api-1.8.0-sbom.json

Software Artifact

Висновок

  • binaries;
  • packages;
  • container images;
  • mobile apps;
  • firmware;
  • release archives;
  • enterprise software;
  • open source distribution. * Docker image — один із найпопулярніших сучасних software artifacts. app.zip

Типовий сценарій:

</syntaxhighlight>

Artifact і Reproducible Build

Test Artifact

|- | Artifact | Результат процесу або роботи | Build output, test report, release package |- | Asset | Ресурс, який застосовується для продуктом | Image, icon, sound, 3D model |}

Secrets не повинні потрапляти в artifacts. Практична роль: immutable artifact дає можливість бути впевненим, що “реліз системи 1.2.3” сьогодні й завтра означає той самий вміст. У software development artifacts допомагають зробити бізнес-процес відтворюваним, перевірним і керованим. Deliverable — те, що команда обіцяє передати замовнику або stakeholder-у. Build once, deploy many

Практична роль: checklist оптимізує не перетворити реліз на “ми десь зібрали якийсь файл”. Приклад

  • creation;
  • validation;
  • storage;
  • scanning;
  • approval;
  • promotion;
  • deployment;
  • monitoring;
  • rollback use;
  • archival;
  • deletion. Приклади:
Вони потрібні для:

'''Artifact''' — це конкретний результат роботи: файл, пакет, image, звіт, модель, документація, дизайн, лог або інший матеріал, який створюється в процесі розробки, тестування, збірки, релізу чи дослідження. У project management artifact — це документ або результат, який оптимізує керувати роботою.== Приклад artifact naming ==

 test-report.xml
! Registry здатна зберігати:
Команда збирає frontend bundle, backend Docker image, database migration scripts і release notes. це результат роботи, який створюється, зберігається або передається в процесі розробки, тестування, збірки, доставки чи експлуатації системи виступає ключовою рисою '''Artifact''' або '''артефакт'''. * 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. Ось звідки він узявся”.== Artifact і Configuration ==
Один artifact здатна розгортатися в різні environments:
Release artifact має бути:

== ML Artifact ==

<syntaxhighlight lang="text">
</div>
<syntaxhighlight lang="bash">

У research artifact — це результат дослідження або експерименту.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Research artifacts важливі для:

'''Documentation artifact''' — документ або матеріал, який описує систему, рішення для бізнесу, бізнес-процес або ERP-продукт.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">
== Data Artifact ==

'''критично:''' binary artifact важче перевірити очима, ніж source code, тому для нього важливі signatures, checksums, provenance і trusted build pipeline.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

У CI-системах на кшталт GitHub Actions artifact часто означає файл, який workflow зберігає після job. Artifact пов’язаний із Git commit або tag
'''Цікавий факт:''' wireframe — це теж artifact, хоча він не запускається як програма. * build outputs;
* test reports;
* coverage reports;
* logs;
* screenshots;
* compiled binaries;
* Docker images;
* deployment packages;
* static analysis reports;
* security scan reports;
* SBOM;
* Terraform plans.

Retention policy визначена Приклади:

Коли artifacts можна спростити

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

Checksum — коротке значення, яке оптимізує перевірити цілісність artifact. orders-api-1.8.0-linux-amd64.tar.gz

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

  • source code;
  • binaries;
  • libraries;
  • packages;
  • container images;
  • configuration files;
  • scripts;
  • database schemas;
  • API contracts;
  • documentation;
  • test data;
  • build outputs;
  • deployment manifests. Checksum створено

Приклади: Build artifact

Package artifact — artifact у форматі package manager.

Package Artifact

Artifact у Software Supply Chain

Artifact і Dependency

  • 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. Практична роль: бібліотека як package artifact здатна бути dependency для застосунку. * Хороший artifact здатна пережити людей у команді: через роки він пояснить, що саме було випущено.== Artifact і Environment ==

</syntaxhighlight>

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

Практична роль: project artifact оптимізує команді пам’ятати не тільки що робити, а й чому це робиться. Для logs і temporary reports часто достатньо короткого retention. Найлюдяніший факт: artifact — це спосіб не покладатися на пам’ять людей. Checksum оптимізує зрозуміти:

my-app:git-a1b2c3d

Практична роль: registry — це складський облік артефактів, звідки CI/CD, Kubernetes або production бере конкретні images.== Build Artifact == Artifact і dependency пов’язані, але не одне й те саме.== Artifact і Source Code ==

Потрібно контролювати:

  • dataset;
  • data snapshot;
  • cleaned CSV;
  • Parquet file;
  • report;
  • dashboard export;
  • data quality report;
  • feature set;
  • anonymized dataset;
  • data schema;
  • migration output. Практична порада: що важливіший ERP-продукт, то важливіше знати не тільки “який код”, а й “який artifact” функціонує в production. Він фіксує рішення для бізнесу про майбутню взаємодію користувача із системою. Це зафіксований результат процесу, якому команда має вміти довіряти. * ML model без metadata — слабкий artifact, бо його важко відтворити й оцінити. Release approval

Training pipeline створює model weights, tokenizer, evaluation report, metrics, dataset version і model card. Він каже: “Ось конкретний результат. my-app:2026.05.09

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

Run tests

Release artifacts можуть включати:

Immutable artifact — artifact, який після створення не змінюється. orders-api-1.8.0-checksums.txt

  • хто створив artifact;
  • чи змінювався artifact після підпису;
  • чи можна довіряти джерелу;
  • чи artifact походить із правильного pipeline. Поняття

Практична роль: у game development artifacts часто включають не тільки код, а й велику кількість творчих assets. Rollback artifact доступний Приклади:

Rollback часто залежить від наявності попереднього artifact. Package artifact зазвичай має:

Приклади registry:

критично: artifact більше підкреслює походження з процесу, а asset — корисність як ресурс. Приклади:

  • analytics;
  • reproducibility;
  • ML;
  • audit;
  • reporting;
  • data pipelines;
  • compliance;
  • debugging.
    Tests пройшли
Приклад:
== Artifact Retention ==
'''Практична роль:''' ML artifact — це не тільки файл моделі.== Provenance ==

Log artifacts можуть бути:

* зберегти попередню версію;
* знати, який artifact був deployed;
* мати compatible database state;
* мати rollback plan;
* мати доступ до registry;
* мати deployment automation;
* мати logs і monitoring. Artifact repository оптимізує:

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

* development;
* testing;
* staging;
* production;
* preview;
* disaster recovery. Приклад

</div>
</div>
</div>

<syntaxhighlight lang="text">

'''Головна думка:''' artifact — це не без зусиль файл. як приклад, згенерований sprite sheet виступає як asset для гри й artifact build-процесу.{{SEO
|title=Artifact — артефакт у програмуванні, розробці ПЗ, DevOps, дизайні, даних і документації
|description=Artifact — Wiki-стаття про артефакт як результат роботи або проміжний продукт у software development, DevOps, CI/CD, дизайні, тестуванні, машинному навчанні, документації й управлінні проєктами. Розглянуто build artifacts, release artifacts, Docker images, packages, binaries, test reports, logs, documentation artifacts, design artifacts, ML artifacts, repositories, versioning, provenance, SBOM, безпеку, переваги, ризики, цікаві факти і хороші практики.
|keywords=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
|alternativeTo=ручна передача файлів між командами; неверсіоновані build-файли; хаотичні zip-архіви; deployment без reproducible artifact; релізи без checksum і provenance; збереження результатів збірки лише локально; документація без версій; ML-моделі без metadata; CI/CD без збереження test reports і logs
}}
 provenance.json

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

Такі artifacts допомагають команді думати спільно й не втрачати контекст користувача. Приклад хорошої ідеї:

Артефакти мають бути версіоновані. '''Практична роль:''' research artifact дає можливість не лише сказати “ми отримали результат”, а й показати, як саме його отримали. Погано:

У regulated або enterprise-середовищах artifacts важливі для compliance. У розробці ПЗ артефакт часто важливіший, ніж здається. Стара діаграма здатна вводити команду в оману. Приклади:
<syntaxhighlight lang="text">
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

</div>
== Release Artifact ==
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

Build system

'''Найлюдяніший факт:''' artifact — це як готова коробка з продуктом. Рекомендовано:

</div>

* suspicious binary;
* log file;
* packet capture;
* memory dump;
* malware sample;
* IOC list;
* forensic image;
* audit event;
* incident timeline;
* hash;
* screenshot;
* YARA rule. Приклади:
Один artifact

Deploy artifact

Project Management Artifact

  • semantic versioning;
  • build number;
  • Git commit SHA;
  • date-based version;
  • release tag;
  • image digest;
  • package version;
  • environment-specific label. як приклад, команда здатна написати чудовий код, але production запускає не “код із GitHub”, а конкретний build artifact: container image, binary, package або compiled bundle.== Mutable Tags ==

SBOM створено для важливого релізу

Signing або підпис artifact оптимізує перевірити його походження й цілісність.

Небезпека: погано керовані artifacts можуть перетворити CI/CD із системи довіри на систему випадкових файлів. Спрощення доречне, якщо: Краще: Приклади:

Artifact у GitHub Actions

  • 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. coverage-report.html
  • `.exe`;
  • `.dll`;
  • `.so`;
  • `.dylib`;
  • `.jar`;
  • `.class`;
  • `.wasm`;
  • compiled CLI tool;
  • mobile app binary;
  • firmware image. Поняття

Критично: якщо secret потрапив в artifact, його потрібно вважати скомпрометованим і rotate, а не без зусиль видалити файл у наступному build. як приклад, image з digest:

  • empathy map;
  • persona;
  • user journey map;
  • problem statement;
  • prototype;
  • wireframe;
  • usability report;
  • workshop board;
  • decision matrix.

Один artifact здатна сам стати dependency для іншого проєкту. * `latest` — зручний tag, але поганий спосіб описати release artifact у production. Deployment

</syntaxhighlight>

Практична роль: documentation artifact зберігає знання команди, щоб вони не жили тільки в головах кількох людей. Якщо зловмисник підмінив package або image, production здатна запустити шкідливий код навіть без зміни source repository. Secrets не включені

Приклад структури release artifacts

latest-prod-real.zip

Практична роль: така структура показує не тільки сам build, а й докази якості, походження й готовності до релізу. * `.env` у Docker image;

  • private key у package;
  • access token у build logs;
  • password у test report;
  • credentials у static bundle;
  • API key у mobile app без захисту;
  • secrets у source maps. Погано керовані artifacts створюють ризики: підміна, secrets у build, незрозумілі версії, неможливість rollback і хаос у release process. frontend-dist.zip
Build pipeline створює `.jar`, генерує documentation, підписує package і публікує його в Maven repository.

Головне правило: хороший artifact має бути зрозумілим, перевіреним, версіонованим, захищеним і пов’язаним із джерелом свого походження. Підказка: якщо файл оптимізує зрозуміти, перевірити або повторити результат роботи, він майже точно виступає як artifact. Test artifacts допомагають:

Artifact repository — спеціальне сховище для build, package і release artifacts. Збирати окремий artifact для production із hardcoded секретами </syntaxhighlight>

Artifact і Rollback

Ризики artifacts

== Artifact у Game Development ==
'''Практична порада:''' artifact має бути однаковим, а environment-specific поведінка має керуватися конфігурацією, не секретами всередині build. Типові етапи:
Artifact здатна мати retention time, тобто зберігатися обмежений час. '''Software artifact''' — будь-який створений у процесі розробки програмний або технічний результат. Docker image містить:

* name;
* version;
* dependencies;
* metadata;
* license;
* checksum;
* package manifest;
* distribution registry. * debugging;
* incident analysis;
* audit;
* troubleshooting;
* performance analysis;
* compliance;
* root cause analysis. У machine learning '''ML artifact''' — це результат навчання, оцінки або deployment моделі. '''Практична роль:''' software supply chain дивиться на artifact як на ланку між розробкою й користувачем. * Матеріали DevOps щодо release management, artifact repositories і deployment pipelines. Код — це рецепт, pipeline — це кухня, а artifact — те, що реально їде до користувача. '''Критично:''' artifact здатна бути атакований у supply chain. '''Практична роль:''' Docker image робить deployment більш передбачуваним, бо застосунок і його залежності пакуються разом.
  • security;
  • trust;
  • open source;
  • audit;
  • deterministic releases;
  • supply chain verification;
  • debugging. Головна перевага: artifact робить результат роботи конкретним: його можна назвати, зберегти, перевірити й використати. Для rollback потрібно:

Погана практика:

Artifact repository

  • dataset;
  • notebook;
  • experiment log;
  • paper draft;
  • chart;
  • model output;
  • benchmark result;
  • survey data;
  • transcript;
  • analysis report;
  • replication package. * Artifact repository — важлива частина software supply chain.

Практична роль: CI artifact дає можливість не втратити результат job після завершення pipeline.== Container Registry == 

Найважливіші artifacts у сучасному DevOps — це build artifacts, release artifacts, container images, packages, test reports, SBOM, provenance і documentation. Один файл здатна бути і asset, і artifact.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Log artifact''' — файл або набір логів, збережених після запуску, тесту, build або incident.</div>
<syntaxhighlight lang="text">
Небезпечні приклади:
У цьому прикладі `my-app:1.0.0` виступає як container artifact. '''Architecture artifact''' — матеріал, який описує архітектуру системи. Ось його реліз системи. * image tags;
* image digests;
* layers;
* metadata;
* signatures;
* vulnerability scan results;
* SBOM у частині платформ. * source repository;
* commit SHA;
* branch або tag;
* build system;
* build time;
* builder identity;
* dependencies;
* build parameters;
* test status;
* signatures;
* environment details. Reproducible builds ускладнюються через:
'''Практична роль:''' package artifact дає можливість іншим проєктам встановлювати й використовувати вашу бібліотеку або інструмент через package manager. '''SBOM''' або '''Software Bill of Materials''' — список компонентів, з яких складається software artifact. Security scan

=== Security incident ===

'''критично:''' architecture artifact має бути актуальним. '''критично:''' назва artifact має допомагати зрозуміти, що це, яка реліз системи, для чого й для якої платформи. !<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Container registry''' — сховище для container image artifacts. Data artifacts важливі для:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Джерела ==

 checksums.txt

'''Практична роль:''' compliance часто потребує не лише “ми випустили версію”, а доказів: що саме, коли, ким, як перевірено й із яких компонентів.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
== Versioning ==
Приклади build artifacts:
== Цікаві факти про Artifact ==

</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Основні конкурентні переваги artifacts:

Це критично для:

У CI/CD артефакт — це файл або результат, який pipeline створює й передає між етапами.</div>
Це інтуїтивно для development, але ризиковано для production. Приклад:
</div>

</div>

</div>

'''критично:''' provenance оптимізує відповісти на питання: “Звідки взявся цей artifact і чи можна йому довіряти?”

* які artifacts зберігати;
* як довго;
* де;
* хто має доступ;
* які artifacts критичні для rollback;
* які можна видаляти;
* чи потрібне legal retention;
* чи містять artifacts чутливі інформаційні дані;
* скільки коштує storage.== Artifact і Asset ==

* узгодити очікування;
* перевірити ідею до розробки;
* пояснити user flow;
* зменшити переробки;
* передати дизайн розробникам;
* документувати продуктове рішення для бізнесу. SBOM корисний для:
</div>
</div>

До software artifacts належать:

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

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. |-
| Artifact
| Будь-який результат роботи
| Test log, build file, prototype
|-
| Deliverable
| Результат, який офіційно передають
| Release build, final report, design package
|}

Artifact security — захист artifacts від підміни, витоку й небезпечного використання.</div>

* security;
* license compliance;
* audits;
* vulnerability response;
* supply chain management;
* enterprise governance;
* incident response. final.zip

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
 migrations/
== Artifact у Design Thinking ==

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

</div>

Хороша практика:

* compiled app;
* test report;
* coverage report;
* static site output;
* build directory;
* deployment package.== Приклад checklist для release artifact ==

* test results;
* coverage;
* built app;
* screenshots;
* compiled package;
* logs;
* deployment bundle. Artifact має життєвий цикл. Для production краще використовувати конкретну версію або digest.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
</div>

final2.zip

== Див. так само ==

== Docker Image як Artifact ==
Але навіть у малому проєкті корисно мати:

! CI/CD artifacts можуть бути:

  • wireframe;
  • mockup;
  • prototype;
  • user flow;
  • journey map;
  • design system component;
  • style guide;
  • persona;
  • usability test report;
  • information architecture;
  • Figma file;
  • accessibility notes.
    </div>
</div>

Scan artifact

== Artifact і Secrets ==

'''Проста різниця:''' artifact здатна бути внутрішнім, а deliverable зазвичай має зовнішнє або контрактне значення. Binary artifact важливий, бо він часто виступає як фінальним результатом build process.== Цікавий факт ==
Саме тому сучасний DevOps багато уваги приділяє не лише source code, а й тому, який саме artifact був зібраний, ким, коли, з яких dependencies, з якими тестами, з яким checksum і чи можна довести його походження.=== Java library ===
'''Release artifact''' — artifact, який готовий до випуску або deployment.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

команди забезпечується через Слово '''artifact''' часто означає не “щось стародавнє з музею”, а конкретний файл або набір файлів, який має значення; так само реалізовано процесу чи системи. Artifact збережено в repository або registry

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''Практична роль:''' build artifact — це те, що pipeline створює після компіляції, bundling або packaging. * Test report — теж artifact, хоча він не виступає як програмою.== Приклади сценаріїв використання ==

* onboarding;
* architecture review;
* security review;
* incident analysis;
* planning;
* communication with stakeholders;
* migration;
* compliance.</div>
<syntaxhighlight lang="text">
Security scan виконано

'''критично:''' artifact без версії важко відтворити, перевірити й відкотити. Поширені помилки:

'''критично:''' logs як artifacts мають бути корисними, але не повинні містити passwords, tokens або зайві персональні інформаційні дані. Приклад pipeline:

Artifact здатна бути deliverable, але не завжди.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

</div>

* версіонувати 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 має версію

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

Підписування важливе для:
Приклади:
Artifact здатна бути фінальним або проміжним результатом. orders-api-1.8.0-test-report.xml
'''Design artifact''' — результат UX/UI, product design або visual design роботи.</div>
</div>
== SBOM ==

Dependencies

'''Практична роль:''' artifact lifecycle оптимізує керувати не тільки створенням, а й зберіганням, використанням і видаленням artifacts. Artifact особливо важливий, якщо:

 backend-1.4.2.tar.gz

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

* signed artifacts;
* audit logs;
* SBOM;
* license reports;
* vulnerability scan results;
* approval records;
* release notes;
* test evidence;
* provenance;
* retention policy;
* access control;
* change management records. Не кожен маленький проєкт потребує складної artifact platform. !</div>
!<syntaxhighlight lang="text">
ML artifacts особливо важливі, бо модель без metadata часто важко відтворити. * source artifact — код або archive source;
* build artifact — результат збірки;
* release artifact — те, що випускають;
* deployment artifact — те, що розгортають. * Документація CI/CD систем щодо build artifacts і job artifacts. '''Build artifact''' — результат процесу збірки. '''Найлюдяніший факт:''' не кожен artifact має бути кодом. '''критично:''' security artifacts можуть бути чутливими або небезпечними, тому їх потрібно зберігати з контролем доступу й обережністю.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Приклад:

! docker build -t my-app:1.0.0 .

Checkout code Store artifact

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

Architecture artifacts корисні для:

  • build logs;
  • test logs;
  • application logs;
  • deployment logs;
  • security logs;
  • audit logs;
  • container logs;
  • CI job logs.
  • test logs — 7 або 30 днів;
  • release artifacts — кілька років;
  • security reports — згідно з compliance;
  • temporary build outputs — короткий термін;
  • production images — до завершення підтримки версії.</syntaxhighlight>

Критично: якщо artifact можна непомітно підмінити, безпека всього release process під загрозою. * architecture diagram;

  • C4 diagram;
  • sequence diagram;
  • deployment diagram;
  • data flow diagram;
  • ADR;
  • threat model;
  • integration map;
  • infrastructure diagram;
  • service catalog;
  • dependency map.== Signing ==
  • reproducibility;
  • rollback;
  • audit;
  • security;
  • deployment confidence;
  • debugging;
  • traceability.
  • access control;
  • signing;
  • checksums;
  • vulnerability scanning;
  • secret scanning;
  • license scanning;
  • provenance;
  • SBOM;
  • immutable storage;
  • audit logs;
  • retention;
  • dependency policies;
  • trusted builders;
  • registry permissions.

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

Docker image — один із найпоширеніших сучасних release artifacts. new-build.zip

Artifact у Research

Основна ідея: artifact — це “слідом залишений результат роботи”: те, що можна зберегти, перевірити, передати, розгорнути або використати пізніше. * чи artifact не пошкодився;

  • чи файл той самий;
  • чи download завершився коректно;
  • чи artifact відповідає очікуваному digest. * зрозумілі назви;
  • версію;
  • README;
  • простий release archive;
  • backup важливих результатів. Це artifacts, які проходять перевірку перед публікацією.

Data artifact — результат роботи з даними. * Artifact без provenance — як посилка без зворотної адреси. Не варто тестувати один build, а в production збирати інший “майже такий самий”. * називати файл `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. * 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. * Artifact у DevOps часто означає саме те, що реально deploy-иться, а не без зусиль source code.
  • reproducibility;
  • peer review;
  • validation;
  • knowledge transfer;
  • future research;
  • transparency. Критично: якщо старий artifact видалили, rollback здатна перетворитися на emergency rebuild, а це ризиковано.
  • версіонувати artifacts;
  • контролювати доступ;
  • зберігати історію релізів;
  • кешувати dependencies;
  • підтримувати supply chain security;
  • робити rollback;
  • відтворювати releases. * Design mockup здатна бути artifact так само, як binary file. Усі ці файли виступає як artifacts релізу. Небезпека: якщо команда не знає, який artifact зараз у production, incident response стає набагато складнішим. Не кожен проєкт його має, але для security-sensitive software це дуже цінно. Приклади:

Machine learning model

Artifacts мають ризики. * Практики software supply chain security, SBOM, provenance, signing і checksum verification. Binary artifact — скомпільований файл або пакет, який здатна виконуватися або використовуватися іншими програмами. Для pet project і банківської системи рівень контролю має бути різним.

Приклади:

Приклади:

Типовий ланцюг:

</syntaxhighlight>

Architecture Artifact

Проста аналогія: artifact repository — це бібліотека готових збірок, а не випадкова папка Downloads на ноутбуці розробника. Provenance — інформаційні матеріали про походження artifact.
  • timestamps;
  • random values;
  • різні dependency versions;
  • різні OS packages;
  • network downloads;
  • build environment differences. * хто створив artifact;
  • з якого коду;
  • з якими dependencies;
  • чи проходив тести;
  • чи був підписаний;
  • де зберігався;
  • хто мав доступ;
  • який artifact реально запущений. {| class="wikitable"

Design artifacts допомагають:

У цьому прикладі `dist/app.bundle.js` виступає як build artifact. Практична роль: CI/CD artifact — це “передавальний предмет” між етапами pipeline: зібрали, перевірили, зберегли, розгорнули.
  • npm package;
  • Python wheel;
  • Maven package;
  • NuGet package;
  • Ruby gem;
  • Go module;
  • Debian package;
  • RPM package;
  • Composer package;
  • Cargo crate. staging

Приклади:

критично: `latest` — не реліз системи, а рухома мітка. SBOM здатна містити:

Test artifact — результат тестування.
'''Reproducible build''' — бізнес-процес, у якому з однакового source code і однакових умов можна отримати той самий artifact.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

Configuration здатна містити:

* відтворюваність;
* traceability;
* простіший deployment;
* кращий rollback;
* evidence для testing;
* release discipline;
* auditability;
* supply chain security;
* можливість перевірки;
* зручне зберігання;
* командна передача результатів;
* automation;
* контроль версій;
* separation between build and deploy. Суть

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

Design Artifact

Доступ до artifact обмежений

У software supply chain artifact проходить шлях від source code до production. через Проста думка: software artifact — це не тільки готова програма.

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

Перевага: artifacts роблять роботу команди відтворюваною: можна побачити, що саме було створено, протестовано й доставлено. Можуть вимагатися:

Приклади retention:

Практична роль: якщо один і той самий artifact проходить staging і production, команда менше ризикує отримати “у staging працювало, бо build був інший”. Приклади:

  • виступає як production deployment;
  • потрібен rollback;
  • платформа regulated;
  • ERP-продукт має багато environments;
  • виступає як CI/CD;
  • застосовується для Docker або Kubernetes;
  • виступає як packages для клієнтів;
  • потрібна supply chain security;
  • команда велика;
  • потрібен audit;
  • релізи мають підписуватися;
  • ML-моделі потрібно відтворювати;
  • потрібно довести, що саме було протестовано. Суть

Web application release

<syntaxhighlight lang="text">

  • application files;
  • runtime;
  • dependencies;
  • filesystem layers;
  • default command;
  • metadata;
  • environment assumptions;
  • labels;
  • exposed ports. main
sbom.json

Checksums

Artifact підписано, якщо потрібно Поширені підходи: dev

Приклади artifacts:

  • database URL;
  • feature flags;
  • API endpoints;
  • environment name;
  • log level;
  • external service settings.

Artifact і Deliverable

CI створює Android APK або AAB, iOS build, test reports і screenshots. * це навчальний проєкт;

  • немає production;
  • немає external releases;
  • немає compliance;
  • build artifacts швидко відтворити;
  • команда маленька;
  • artifacts тимчасові;
  • немає чутливих даних. 001_add_invoice_table.sql

library-2.8.0.jar

Отримано з https://wiki.kyiv.ua/index.php?title=Artifact&oldid=1382