ソフトウェアリポジトリ

ソフトウェア リポジトリ(略してrepo)は、ソフトウェア パッケージの保存場所です。多くの場合、メタデータとともに目次も保存されます。ソフトウェア リポジトリは通常、ソースコントロールまたはバージョン コントロール(リポジトリ マネージャー) によって管理されます。パッケージ マネージャーを使用すると、リポジトリ (「パッケージ」と呼ばれることもあります) を自動的にインストールおよび更新できます。

多くのソフトウェア発行者やその他の組織は、この目的のためにインターネット上にサーバーを無料またはサブスクリプション料金で維持しています。リポジトリは、Perlプログラミング言語のCPANなど特定のプログラム専用の場合もあれば、オペレーティングシステム全体の場合もあります。このようなリポジトリの運営者は通常、リポジトリからソフトウェアパッケージを検索、インストール、および操作するためのツールであるパッケージ管理システムを提供します。たとえば、多くのLinuxディストリビューションは、 Debianベースのディストリビューションで一般的に使用されているAdvanced Packaging Tool (APT)、またはRed Hatベースのディストリビューションで使用されているYellowdog Updater, Modified ( yum )を使用しています。また、 Arch Linuxで使用されるpacmanやSabayon Linuxで使用されるequoなど、複数の独立したパッケージ管理システムもあります。

ソフトウェアリポジトリは便利なパッケージを含むように設計されているので、主要なリポジトリはマルウェアフリーになるように設計されています。コンピュータが評判の良いベンダーのデジタル署名されたリポジトリを使用するように構成され、適切な権限システムと組み合わせられている場合、これらのシステムに対するマルウェアの脅威は大幅に軽減されます。副作用として、これらの機能を備えた多くのシステムでは、ウイルス対策ソフトウェアなどのマルウェア対策ソフトウェアは必要ありません。^[1]

ほとんどの主要なLinux ディストリビューションには、メイン リポジトリをミラーリングするリポジトリが世界中に多数あります。

クライアント側では、パッケージ マネージャーがリポジトリからのインストールと更新を支援します。

パッケージ管理システムは、パッケージ開発プロセスとは異なります。

パッケージ管理システムの典型的な用途は、異なるソースからのコードを、一貫性のあるスタンドアロンのオペレーティング ユニットに統合できるようにすることです。したがって、パッケージ管理システムは、特定の制限されたアプリケーションに合わせて調整された Linux ディストリビューションを作成するために使用される可能性があります。

対照的に、パッケージ開発プロセスは、共通のテーマを持つ関数またはルーチンのコレクションのコードとドキュメントの共同開発を管理するために使用され、それによって、通常はそれ自体では完全で使用できないソフトウェア関数のパッケージが作成されます。優れたパッケージ開発プロセスは、ユーザーが適切なドキュメントとコーディングのプラクティスに準拠し、ある程度のユニット テストを統合するのに役立ちます。

次の表には、寄贈されたソフトウェアのリポジトリを持つ言語がいくつかリストされています。「自動チェック」列には、実行される定期的なチェックが説明されています。

複数のオペレーティング システムで、コア コードの異なるバージョンや、使用する可能性のある他の提供パッケージを使用して、ソフトウェアをテストできる人はほとんどいません。Rプログラミング言語の場合、Comprehensive R Archive Network (CRAN) が定期的にテストを実行します。

これがいかに貴重であるかを理解するために、サリーとジョンという 2 人の開発者がいる状況を想像してください。サリーはパッケージ A を提供します。サリーは、ソフトウェアの現在のバージョンを 1 つのバージョンの Microsoft Windows でのみ実行し、その環境でのみテストしています。CRAN は、ほぼ定期的に、サリーの提供物をオペレーティング システムとコア R 言語ソフトウェアのバージョンの 12 の組み合わせでテストします。そのうちの 1 つでエラーが発生すると、そのエラー メッセージが表示されます。運が良ければ、そのエラー メッセージの詳細から、現在のハードウェアとソフトウェアでエラーを再現できない場合でも、エラーを修正できる十分な情報が得られる可能性があります。次に、ジョンがパッケージ A を使用するパッケージ B をリポジトリに提供するとします。パッケージ B はすべてのテストに合格し、ユーザーが使用できるようになります。その後、サリーは A の改良バージョンを提出しますが、残念ながら、パッケージ B が壊れてしまいます。自動チェックにより、ジョンに情報を提供して問題を修正できるようになります。

この例は、R の寄贈パッケージ システムの長所と短所の両方を明らかにしています。CRAN は、寄贈パッケージのこの種の自動テストをサポートしていますが、CRAN に寄贈されたパッケージは、使用する他の寄贈パッケージのバージョンを指定する必要はありません。パッケージの特定のバージョンを要求する手順は存在しますが、寄贈者はそれらの手順を使用しない可能性があります。

さらに、CRAN などのリポジトリは、寄贈されたパッケージを定期的にチェックすることで、コア言語の開発バージョン用の広範な if ad hocテスト スイートを実際に提供します。Sally (上記の例) が、特に言語の開発バージョンから、理解できない、または不適切と思われるエラー メッセージを受け取った場合、彼女はその言語のコア開発チームに支援を求めることができます (R ではよくそうします)。このようにして、リポジトリはコア言語ソフトウェアの品質向上に貢献できます。

（この表の一部は、 Stack Overflowの「プログラミング言語別トップリポジトリリスト」^[20]からコピーしたものです）

C、C++、Fortranなど、他の多くのプログラミング言語には、普遍的なスコープを持つ中央ソフトウェア リポジトリがありません。スコープが限定されている注目すべきリポジトリには、次のものがあります。

• Netlib は、主に Fortran と C 用の数学ルーチンで、歴史的に最初のオープン ソフトウェア リポジトリの 1 つです。
• Boost は、C++ 用の厳選された高品質ライブラリのコレクションです。Boost で開発された一部のコードは、後に C++ 標準ライブラリの一部になりました。

パッケージ マネージャーは、リポジトリとその配布の管理に役立ちます。リポジトリが更新されると、パッケージ マネージャーは通常、ユーザーがパッケージ マネージャーを通じてそのリポジトリを更新できるようにします。また、他のソフトウェア リポジトリ間の依存関係などの管理にも役立ちます。パッケージ マネージャーの例には、次のものがあります。

企業環境では、ソフトウェア リポジトリは通常、成果物を保存したり、セキュリティ制限のためにアクセスできない可能性のある外部リポジトリをミラーリングするために使用されます。このようなリポジトリは、アクセス制御、バージョン管理、アップロードされたソフトウェアのセキュリティ チェック、クラスター機能などの追加機能を提供する場合があり、通常は 1 つのパッケージでさまざまな形式をサポートして、企業内のすべてのニーズに対応し、単一の真実を提供することを目指しています。一般的な例としては、JFrog Artifactory ^{[29] [30]、} Sonatype Nexus Repository ^[31]、クラウドベースの製品である Cloudsmith ^{[32]などがあります。}

サーバー側では、ソフトウェア リポジトリは通常、ソース コントロールまたはリポジトリ マネージャーによって管理されます。リポジトリ マネージャーの中には、他のリポジトリの場所を 1 つの URL に集約し、キャッシュ プロキシを提供するものもあります。継続的なビルドを行うと、多くの成果物が生成され、集中的に保存されることが多いため、リリースされない成果物を自動的に削除することが重要です。

開発ライフサイクルの一環として、継続的インテグレーションを使用して、ソース コードは継続的にバイナリ成果物に組み込まれます。これにより、開発者がリポジトリから成果物を取得してそこにビルドをプッシュするのと同じように、バイナリ リポジトリ マネージャーとやり取りできます。CI サーバーとの緊密な統合により、次のような重要なメタデータを保存できます。

• どのユーザーがビルドをトリガーしたか（手動でか、リビジョン管理にコミットしてか）
• どのモジュールが構築されたか
• 使用されたソース (コミット ID、リビジョン、ブランチ)
• 使用される依存関係
• 環境変数
• インストールされたパッケージ

アーティファクトとパッケージは本質的に異なる意味を持ちます。アーティファクトは単にファイルの出力またはコレクション（例：JAR、WAR、DLL、RPMなど）であり、それらのファイルの1つにメタデータ（例：POMファイル）が含まれている場合があります。一方、パッケージは、パッケージタイプ（例：DLL、PDB）に適したファイルを含む、明確に定義された形式（例：NuGet）の単一のアーカイブファイルです。^[33]多くのアーティファクトはビルドから生成されますが、他のタイプも重要です。パッケージは基本的に、ライブラリまたはアプリケーションの2つのいずれかです。^[34]

ソース ファイルと比較すると、バイナリ成果物は桁違いに大きいことが多く、削除または上書きされることはほとんどありません (スナップショットや夜間ビルドなどのまれなケースを除く)。また、通常は ID、パッケージ名、バージョン、ライセンスなどの多くのメタデータが付随します。

メタデータはバイナリ アーティファクトを記述し、アーティファクト自体とは別に保存および指定され、いくつかの追加の用途を持つことができます。次の表は、一般的なメタデータの種類とその用途を示しています。