「アーティファクトリポジトリとは」に関する質問には、そのリポジトリの部分に関する興味深い説明を含む回答が含まれています。そして、答え全体を読んで、DevOpsのコンテキストで「アーティファクト」が正確に何を意味するのかわかりません。
助言がありますか？
追伸：答えの1つから、おそらく人工物が私が疑問に思っている（混乱している）ことを理解しているようです...
回答:
ウィキペディアには、この質問に対する非常に良い答えがあります。アーティファクトは、派生オブジェクトとも呼ばれることもありますが、コードリポジトリに適用されるプロセスの成果物です。当初はビルドアーティファクトと呼ばれていましたが、ビルド以外のプロセスが適用されて作成されたため、最初の言葉は単純に削除されました。
主な違いは、プロセスが適用された環境を保持している限り、同じプロセスを使用してコードリポジトリからアーティファクトを再作成できることです。このプロセスには時間がかかり、環境を不完全に保存して、アーティファクトをまったく同じ方法で再作成できるため、アーティファクトリポジトリに格納するようになりました。
離れてからそれらを保存するコードリポジトリにアーティファクトリポジトリは、 DevOpsチームのエンジニアが作るだろう設計上の決定です。一部の企業、つまりPerforceは、コードリポジトリをアーティファクトリポジトリとしても使用することを提案しています。各リポジトリには、アクセス、監査、オブジェクトサイズ、オブジェクトのタグ付け、およびスケーラビリティに関するさまざまな要件があるため、状況に応じて、2つの異なる製品を使用する方がよい場合がよくあります。たとえば、Gitリポジトリはすべての開発マシンに完全にコピーされるため、アーティファクトをコードリポジトリに格納すると、理由を超えてサイズが大きくなりますが、最近ではこれを緩和する方法があります。別の決定は、どのアーティファクトを保存するかです。再構築を高速化するために、中間のアーティファクトを個々のオブジェクトファイルとして保存する会社もあれば、単に最終的なバイナリのみを保存する会社もあります。すべてのアーティファクトに同じ値があるわけではありません。リリースビルドに起因するアーティファクトには、開発者ビルドに起因するアーティファクトとは異なる要件がある場合があります。
最も一般的なアーティファクトは、構成、前処理、コンパイル、リンク、自動テスト、アーカイブ、パッケージング、メディアファイルの作成と処理、データファイルの生成、ドキュメント解析、コード分析、QAなどのプロセスの結果です。
「アーティファクト」という言葉には2つの使用法があり、1つはソースコードをアーティファクトにし、2つ目はアーティファクトではないようにします。
具体的なものとしての「アーティファクト」と理想的なもの –この意味は、「人間によって作られたオブジェクト、通常は文化的または歴史的な興味の対象」という言葉の一般的な意味であり、専門用語ではありません。技術的なコンテキストの例を次に示します。ソフトウェアをデバッグするとき、ソフトウェアについて何かを学びます。この学習を回帰テストのようなソフトウェア成果物に変えることは、しばしば貴重な投資です。そうしないと、この学習は忘れられ、それを習得するための努力は無駄になります。この意味で、ソースコードはアーティファクトと見なされます。
レシピによって生成されるものとしての「アーティファクト」 –この意味は、難解なレシピを使用する錬金術師の一般的なイメージを使用して、しばしばアーティファクトと呼ばれる魔法のデバイスを生成します。錬金術師の比phorのレシピに対応するソースコードと、錬金術師の比phorのアーティファクトに対応するソースコードから派生したものを区別するために使用される技術用語です。たとえば、plop-fizzプログラムのアーティファクトの生成を自動化しただけで、ソースtarball、署名ファイル、DEB、およびRPMパッケージをすべて1つのコマンドでインスタンス化できるようになりました！ この意味は、ソースコードから生成されるものを示すためにこの用語が使用されるため、ソースコードをアーティファクトとして認識しません。
答えは場所によって異なると思います。現在作業している場所では、開発に使用されるソースコードを除き、アーティファクトは他のエンティティによって消費されます。これはソース管理になります。
これには、製品またはその他の必要な製品のバイナリ、ライブラリ、オブジェクトファイル、メディアファイルやテストデータなどのテストアーティファクトが含まれます。
ソースコードはアーティファクトとは見なされません。「消費者」の定義に一致しない場合-サードパーティのライブラリ、テストまたはその他の目的で使用されるスクリプトコード（開発バージョン自体ではない）など。
文化面のサイドノート。DevOpsでは、「アーティファクトリポジトリ」の概念を特定の状況と見なしますが、組織プロセスとはそれほど関連していないようです。
文化の問題：組織がITILを使用している場合、認定された人々は「作成したソフトウェア構成アイテムを配置するためのリポジトリなど、明確なメディアライブラリが必要です」と言うでしょう。したがって、適切に構造化されたITプロセスを気にする人は、どの（非管理）ツールがそれをサポートし、使用されているかを知りません。逆に、NexusまたはArtifactory言語の正当化が必要な場合、組織によっては説明するのが難しい場合があります。
さらに読む：https : //en.wikipedia.org/wiki/Definitive_Media_Library