Co to jest artefakt (lub artefakt)?

Pytanie o „ Co to jest repozytorium artefaktów? ” Zawiera odpowiedź z interesującym wyjaśnieniem części repozytorium. A po przeczytaniu całej odpowiedzi nie jestem pewien, co dokładnie oznacza „ artefakt ” w kontekście DevOps.

Jakieś sugestie?

Ps: Z jednej z odpowiedzi wydaje mi się, że rozumiem, że może artefakt jest tym, o czym zastanawiam się (mylić?)…

Wikipedia ma bardzo dobrą odpowiedź na to pytanie. Artefakt , czasami nazywany także obiektem pochodnym , jest produktem pewnego procesu zastosowanego do repozytorium kodu . Początkowo były one nazywane artefaktami kompilacji , ale ponieważ zastosowano więcej procesów niż build, aby je utworzyć, pierwsze słowo zostało po prostu usunięte.

Główną różnicą jest to, że artefakty można odtworzyć z repozytorium kodu przy użyciu tego samego procesu, pod warunkiem zachowania środowiska, w którym proces został zastosowany. Ponieważ ten proces może być czasochłonny, a środowisko może zostać niedoskonale zachowane, aby móc odtworzyć artefakty w ten sam sposób, zaczęliśmy przechowywać je w repozytoriach artefaktów .

Przechowywanie ich poza Code Repository w Artifact Repozytorium jest decyzja projektowa inżynier devops stałaby. Niektóre firmy, a mianowicie Perforce , sugerują również korzystanie z repozytorium kodów jako repozytorium artefaktów. Istnieją różne wymagania w zakresie dostępu , badania , wielkości obiektów , obiekt tagging i skalowalność na każdym repozytorium, a więc w zależności od sytuacji, często lepiej jest użyć dwóch różnych produktów. Na przykład Gitrepozytoria są kopiowane w całości na każdą maszynę programistyczną, więc przechowywanie artefaktów w repozytorium kodu zwiększyłoby jego rozmiar ponad wszelką przyczynę, chociaż ostatnio istnieją sposoby na złagodzenie tego. Kolejną decyzją jest wybór artefaktów do przechowywania. Niektóre firmy przechowują nawet pośrednie artefakty jako pojedyncze pliki obiektów, aby przyspieszyć ponowne kompilacje, inne przechowują tylko końcowe pliki binarne. Nie wszystkie artefakty mają tę samą wartość. Artefakty wynikające z kompilacji wersji mogą mieć inne wymagania niż artefakty powstałe w kompilacji programisty.

Najczęstsze artefakty to wyniki następujących procesów: Konfiguracja , przetwarzanie wstępne , kompilacja , łączenie , automatyczne testowanie , archiwizacja , pakowanie , tworzenie i przetwarzanie plików multimedialnych , generowanie plików danych , analizowanie dokumentacji , analiza kodu , kontrola jakości itp.

Istnieją dwa sposoby użycia słowa „artefakt”, a jeden powoduje, że kod źródłowy jest artefaktem, a drugi sprawia, że ​​nie jest on artefaktem: może to być naprawdę mylące!

„Artefakt” jako rzecz konkretna, a rzecz idealna - znaczenie to jest powszechnym znaczeniem słowa „przedmiot wykonany przez człowieka, zwykle o znaczeniu kulturalnym lub historycznym” i nie jest technicznym żargonem. Oto przykład w kontekście technicznym: debugując oprogramowanie, dowiadujesz się czegoś o nim. Często cenną inwestycją jest przekształcenie tego uczenia się w artefakt oprogramowania, taki jak test regresji. W przeciwnym razie nauka ta zostanie zapomniana, a wysiłek włożony w jej zdobycie zostanie zmarnowany. W tym znaczeniu kod źródłowy jest uważany za artefakt.

„Artefakt” jako coś wytworzonego przez przepis - To znaczenie wykorzystuje popularny wizerunek alchemika używającego jakiegoś ezoterycznego przepisu do wytworzenia magicznego urządzenia, często nazywanego artefaktem. Jest to żargon techniczny używany do rozróżnienia między kodem źródłowym, który odpowiada przepisowi w metaforze alchemika, a wszystkim, co pochodzi z tego kodu źródłowego, który odpowiada artefaktowi w metaforze alchemika. Na przykład właśnie zautomatyzowałem produkcję artefaktów dla mojego programu plop-fizz, teraz źródłowe pliki archiwów, pliki sygnatur, pakiety DEB i RPM mogą być tworzone w jednym poleceniu! To znaczenie nie rozpoznaje kodu źródłowego jako artefaktu, ponieważ termin jest używany do oznaczenia tego, co powstaje z tego kodu źródłowego.

Przypuszczam, że odpowiedź może się różnić w zależności od miejsca. Tam, gdzie w tej chwili pracuję, artefakt jest czymś pochłoniętym przez jakąś inną istotę, z wyjątkiem kodu źródłowego używanego do programowania - dotyczy to kontroli źródła.

Obejmuje to pliki binarne produktu lub innych potrzebnych produktów, bibliotek, plików obiektowych, artefaktów testowych, takich jak pliki multimedialne lub dane testowe.

Kod źródłowy nie jest uważany za artefakt. Chyba że odpowiada definicji „konsumowany przez” - w naszym przypadku obejmuje biblioteki stron trzecich, kod skryptu używany do testowania lub innych celów (ale nie samą wersję programistyczną).

Uwaga dodatkowa po stronie kultury. Podczas gdy w DevOps uważamy pojęcie „repozytorium artefaktów” za daną sytuację, wydaje się, że nie ma tak dużego powiązania z procesem organizacyjnym.

Problem związany z kulturą: jeśli organizacja korzysta z ITIL, certyfikowani ludzie powiedzieliby: „musimy mieć określoną bibliotekę multimediów, takie repozytorium, aby umieścić wyprodukowane przez nas elementy konfiguracji oprogramowania”. Dlatego osoby, którym zależy na dobrze ustrukturyzowanych procesach IT, nie wiedzą, które narzędzia (niezwiązane z zarządzaniem) obsługują to i są w użyciu. Odwrotnie, jeśli potrzebujesz uzasadnienia dla języka Nexus lub Artifactory, możesz mieć trudności z wyjaśnieniem go w zależności od organizacji.

Dalsza lektura: https://en.wikipedia.org/wiki/Definitive_Media_Library