Що таке артефакт (або артефакт)?

Питання про " Що таке сховище артефактів? " Містить відповідь із цікавим поясненням щодо його частини сховища. І з прочитання всієї відповіді я не впевнений, що саме означає « артефакт » у контексті DevOps.

Будь-які пропозиції?

Пс: З однієї з відповідей я, мабуть, розумію, що, можливо, артефакт - це те, про що мені цікаво (плутати?) ...

У Вікіпедії є дуже гарна відповідь на це питання. Артефакт , який іноді називають також похідним об'єктом , є продуктом певного процесу, застосованого до сховища коду . Спочатку вони називалися Build Artefacts , але оскільки для їх створення було застосовано більше процесів, ніж побудова, перше слово було просто упущено.

Основна відмінність полягає в тому, що артефакти можна відтворити з сховища коду, використовуючи той самий процес, за умови, що ви зберегли середовище, в якому цей процес застосовувався. Оскільки цей процес може зайняти багато часу, а навколишнє середовище може бути збережено недосконало, щоб можна було точно відтворити артефакти точно таким же чином, ми почали зберігати їх у сховищах артефактів .

Зберігання їх крім сховища коду у сховищі артефактів - це дизайнерське рішення, яке може прийняти інженер DevOps. Деякі компанії, а саме Perforce , пропонують також використовувати своє сховище коду як сховище артефактів. Існують різні вимоги щодо доступу , аудиту , розмірів об'єкта , об'єкта мічення і масштабованість на кожному сховищі і тому в залежності від ситуації , часто краще використовувати два різних продуктів. Наприклад, Gitсховища копіюються в повному обсязі на кожну розроблювальну машину, і тому зберігання артефактів у сховищі коду збільшить його розмір поза будь-якими причинами, хоча останнім часом є способи зменшити це. Ще одне рішення - це які артефакти зберігати. Деякі компанії зберігають навіть проміжні артефакти як окремі файли об’єктів, щоб прискорити їх відновлення, інші зберігають просто лише кінцеві бінарні файли. Не всі артефакти мають однакове значення. Артефакти, що виникають у результаті складання версії, можуть пред'являти різні вимоги, ніж артефакти, що виникають у результаті складання розробника.

Найбільш поширені артефакти є результатом наступних процесів: Конфігурація , попередня обробка , Компіляція , язування , автоматизоване тестування , архівування , Упаковка , медіа - файли , створення і обробка , даних Генерація файлів , документації Синтаксичний , код аналізувати , QA , і т.д.

Є два використання слова "артефакт", і одне робить вихідний код артефактом, а друге робить це не артефактом: це дійсно може бути дуже заплутано!

"Артефакт" як конкретна річ, порівняно з ідеальною річчю. Це значення є загальним значенням слова "предмет, зроблений людиною, як правило, культурно-історичний інтерес" і не є технічним жаргоном. Ось приклад в технічному контексті: Коли ви налагоджуєте програмне забезпечення, ви дізнаєтесь щось про програмне забезпечення. Часто цінні інвестиції перетворюють це навчання на програмний артефакт, як тест регресії. Інакше це навчання буде забуто, а зусилля, докладені для його здобуття, будуть марні. У цьому значенні вихідний код вважається артефактом.

"Артефакт" як щось, що виробляється за рецептом. Це значення використовує популярне зображення алхіміка, використовуючи якийсь езотеричний рецепт для створення магічного пристрою, який часто називають артефактом. Це технічний жаргон, який використовується для розмежування вихідного коду, який відповідає рецепту метафори алхіміка, і всього, що походить із цього вихідного коду, що відповідає артефакту в метафорі алхіміка. Наприклад, я просто автоматизував виробництво артефактів для моєї програми plop-fizz, тепер вихідні тарболи, файли підписів, пакети DEB та RPM можна створити лише за одну команду! Це значення не визнає вихідний код як артефакт, оскільки термін використовується для позначення того, що виробляється з цього вихідного коду.

Я думаю, що відповідь може відрізнятися від місця до місця. Там, де я працюю на даний момент, артефакт споживає щось інше, окрім вихідного коду, який використовується для розробки - це переходить до контролю джерела.

Сюди входять двійкові файли продукту чи інших необхідних продуктів, бібліотеки, файли об’єктів, тестові артефакти, такі як медіафайли або тестові дані.

Вихідний код не вважається артефактом. Якщо це не відповідає визначенню "споживається" - в нашому випадку, включаючи сторонні бібліотеки, код сценарію, який використовується для тестування або інших цілей (але не сама версія розробки).

Бічна нота з боку культури. Хоча в DevOps ми розглядаємо концепцію "сховища артефактів" як дану ситуацію, схоже, не так багато зв’язку з організаційним процесом.

Проблема з культурою: якщо організація використовує ITIL, сертифіковані люди сказали б: "нам потрібно мати медіатеку, що визначається, таке сховище для розміщення створених нами елементів конфігурації програмного забезпечення". Тож люди, які піклуються про добре структуровані ІТ-процеси, не знають, які інструменти (не менеджмент) підтримують, які використовуються. І навпаки, якщо вам потрібне обґрунтування мови Nexus або Artifactory, можливо, вам буде важко пояснити це залежно від організації.

Подальше читання: https://en.wikipedia.org/wiki/Definitive_Media_Library