Che cos'è un artefatto (o artefatto)?

17

La domanda su " Che cos'è un repository di artefatti? " Contiene una risposta con una spiegazione interessante sulla parte del repository di esso. E dalla lettura dell'intera risposta, non sono sicuro di cosa significhi esattamente un " artefatto " nel contesto di DevOps.

Eventuali suggerimenti?

Ps: da una delle risposte mi sembra di capire che forse il manufatto è ciò che mi chiedo (confuso?) Di ...

terminology artifacts

— Pierre.Vriens
fonte

2

I nostri amici dell'inglese SE hanno scritto una opinione su "artefatto" vs. "artefatto": english.stackexchange.com/questions/37903/…

— 7ochem

19

Wikipedia ha un'ottima risposta a questa domanda. Il manufatto , talvolta chiamato anche oggetto derivato , è un prodotto di alcuni processi applicati al repository di codice . Inizialmente venivano chiamati Build Artefacts , ma poiché venivano applicati più processi oltre a build per crearli, la prima parola veniva semplicemente eliminata.

La principale distinzione è che gli artefatti possono essere ricreati dal repository di codice usando lo stesso processo, purché tu abbia preservato l'ambiente in cui è stato applicato il processo. Poiché questo processo può richiedere molto tempo e l'ambiente può essere preservato in modo imperfetto per poter ricreare i manufatti nello stesso identico modo, abbiamo iniziato a memorizzarli nei repository di manufatti .

Memorizzarli a parte il repository di codici in un repository di artefatti è una decisione di progettazione che un ingegnere DevOps prenderebbe. Alcune aziende, vale a dire Perforce , suggeriscono di utilizzare il proprio repository di codici anche come repository di artefatti. Esistono requisiti diversi in termini di accesso , controllo , dimensioni degli oggetti , codifica degli oggetti e scalabilità su ciascun repository e quindi, a seconda della situazione, è spesso preferibile utilizzare due prodotti distinti. Ad esempio Giti repository vengono copiati nella loro interezza su ogni macchina di sviluppo e quindi la memorizzazione di artefatti nel repository di codice aumenterebbe le sue dimensioni oltre ogni ragione, anche se ultimamente ci sono modi per mitigare questo. Un'altra decisione da prendere è quali artefatti conservare. Alcune aziende memorizzano anche artefatti intermedi come file di singoli oggetti, per velocizzare le ricostruzioni, altri archiviano semplicemente solo i binari finali. Non tutti gli artefatti hanno lo stesso valore. Gli artefatti risultanti da una build di rilascio potrebbero avere requisiti diversi rispetto agli artefatti derivanti da una build di sviluppatore.

I manufatti più comuni sono i risultati dei seguenti processi: configurazione , preelaborazione , compilazione , collegamento , test automatizzati , archiviazione , packaging , creazione ed elaborazione di file multimediali , generazione di file di dati , analisi della documentazione , analisi del codice , QA , ecc.

— Jiri Klouda
fonte

La frase sulla dimensione di git non è del tutto esatta, usando git lfs puoi mitigare questo problema. (solo una piccola precisione)

— Tensibai

Interessante, ciò conferma ancora di più il mio pensiero (indovinare). 2 cose: il tuo perforce-link ha bisogno di essere risolto e di una domanda aggiuntiva: saresti d'accordo sul fatto che "tenere traccia dei tuoi dati di test" (l'input che hai usato e l'output che hai ottenuto) potrebbe essere considerato anche tale artefatto? E a proposito, questa risposta mi ricorda i "livelli di verifica" utilizzati nell'area del "software escrow" (se ne hai familiarità). Comincio a domandarmi che gli argomenti dell'impegno software dovrebbero essere considerati come argomento per DevOps ... Forse @Tensibai potrebbe voler commentare anche questo?

— Pierre.Vriens

1

@ Pierre.Vriens per i tuoi dati di test, è difficile oggi, se i tuoi dati di test sono un DB, che non si adatta a una nozione di artefatto. Per l'impegno, non ho idea di come sia, se le domande sono abbastanza focalizzate che suona bene per me.

— Tensibai,

@ Pierre.Vriens Voglio dire che ci sono così tante cose che si adattano al nome "dati di test" (da un numero semplice a milioni di file tramite record DB di esempio) che è troppo ampio senza contesto.

— Tensibai,

@ Pierre.Vriens (e scusate Jiri per le notifiche) Non penso che le trattative contrattuali con il vostro fornitore siano in tema, e ciò che descrivete è solo una trattativa legale per quello che immagino.

— Tensibai,

7

Ci sono due usi della parola "artefatto" e uno rende il codice sorgente un artefatto mentre il secondo lo rende non essere un artefatto: questo può davvero essere abbastanza confuso!

"Manufatto" come una cosa concreta, contro una cosa ideale - Questo significato è il significato comune della parola "un oggetto fatto da un essere umano, tipicamente di interesse culturale o storico" e non è un gergo tecnico. Ecco un esempio in un contesto tecnico: quando esegui il debug di un software, impari qualcosa sul software. Spesso è un investimento prezioso trasformare questo apprendimento in un artefatto software, come un test di regressione. Altrimenti questo apprendimento verrà dimenticato e gli sforzi fatti per acquisirlo saranno sprecati. In questo senso, il codice sorgente è considerato un artefatto.

"Artefatto" come qualcosa prodotto da una ricetta - Questo significato usa l'immagine popolare dell'alchimista usando una ricetta esoterica per produrre un dispositivo magico, spesso chiamato artefatto. È il gergo tecnico utilizzato per distinguere tra il codice sorgente, che corrisponde alla ricetta nella metafora dell'alchimista, e qualsiasi cosa derivata da quel codice sorgente, che corrisponde a un manufatto nella metafora dell'alchimista. Ad esempio, ho appena automatizzato la produzione di artefatti per il mio programma plop-fizz, ora i tarball di origine, i file delle firme, i pacchetti DEB e RPM possono essere tutti istanziati in un solo comando! Questo significato non riconosce il codice sorgente come artefatto, poiché il termine viene utilizzato per indicare ciò che viene prodotto da questo codice sorgente.

— Michael Le Barbier Grünewald
fonte

3

Suppongo che la risposta possa variare da un posto all'altro. Dove lavoro al momento un artefatto è qualcosa che viene consumato da qualche altra entità, ad eccezione del codice sorgente utilizzato per lo sviluppo - questo va nel controllo del codice sorgente.

Ciò include file binari del prodotto o altri prodotti necessari, librerie, file di oggetti, artefatti di test come file multimediali o dati di test.

Il codice sorgente non è considerato un artefatto. A meno che non corrisponda alla definizione di "consumato da" - nel nostro caso tra cui librerie di terze parti, codice di script utilizzato per test o altri scopi (ma non la versione di sviluppo stessa).

— RSF
fonte

Interessante, stai confermando quello che stavo indovinando. Saresti d'accordo sul fatto che non importa davvero quale piattaforma o sistema operativo stiamo parlando. Ad esempio, anche per i mainframe si potrebbe "usare" anche questa terminologia ... In tal caso, è possibile includere anche qualcosa al riguardo nella propria risposta, per favore?

— Pierre.Vriens

Anche il codice effettivo dal controllo versione può / dovrebbe essere considerato un artefatto se consumato. Ad esempio, pagine HTML basate su modelli da distribuire così come sono su un sito Web. Sono artefatti di distribuzione, che potrebbero dover essere esplicitamente copiati insieme ad altri artefatti creati in una posizione temporanea per la distribuzione effettiva, ad esempio. Ma potrebbe non avere molto senso memorizzarli in un repository di artefatti poiché possono sempre essere ottenuti dal repository di codice sorgente.

— Dan Cornilescu,

@Pierre Confermando che quale sistema operativo è ortogonale all'essere un artefatto, non sono sicuro del motivo per cui dovrebbe essere incluso nella risposta molte altre cose sono irrilevanti.

— Rsf

0

Nota a margine dal lato della cultura. Mentre in DevOps consideriamo il concetto di "repository di artefatti" come una data situazione, sembra che non ci sia così tanto legame con il processo organizzativo.

Problema di cultura: se un'organizzazione utilizza ITIL, le persone certificate direbbero "dobbiamo disporre di una libreria multimediale definitiva, un repository tale per posizionare gli elementi di configurazione software che abbiamo prodotto". Pertanto, le persone che si occupano di processi IT ben strutturati non sanno quali strumenti (non di gestione) supportano e sono in uso. Viceversa, se hai bisogno di una giustificazione per un linguaggio Nexus o Artifactory, potresti avere difficoltà a spiegarlo a seconda dell'organizzazione.

Ulteriori letture: https://en.wikipedia.org/wiki/Definitive_Media_Library

— Peter
fonte

1

Ciao. Benvenuti nel sito. Si prega di aggiungere ulteriori informazioni alla risposta. Allo stato attuale, è solo link e verrà contrassegnato :)

— Dawny33

se DevOps riguarda anche la cultura, ritengo importante un collegamento a ITIL perché a volte regola l'organizzazione IT a un livello organizzativo più elevato. Aggiunte ulteriori spiegazioni per chiarire questa simmetria dell'ignoranza.

— Peter,

1

Non penso che affronti davvero la questione di cosa sia un artefatto, ma almeno sembra un onesto tentativo di rispondere ora.

— Tensibai,

Sono d'accordo con @Tensibai (ora) e ho eliminato il mio commento precedente (non più sospetto). E anche se tutto in questa risposta ha un senso, non capisco ancora come questa risposta "Nota a margine" affronti la mia domanda, che ho cercato di riassumere anche nel titolo della mia domanda, cioè " Che cos'è un artefatto (o artefatto) )? ". Accolgo con favore nuovi tentativi, ok?

— Pierre.Vriens