Azure Artifacts とは何ですか?

  • 5 分

このユニットでは、Azure Artifacts を使用して、アプリで使用できるパッケージを安全に作成および管理する方法の概要について説明します。

Azure Artifacts が .NET パッケージをホストするための適切な方法であるかどうかを判断し、チームにもう一度チェックインしてください。

マラ： Azure Artifacts で新しい Models パッケージをホストすることは理にかなっているようです。 Microsoft Azure DevOps 組織には既に所属しているため、認証は別のパッケージ マネージャーで設定するよりも簡単です。

アンディ： 私は会議の前にそれを調べて、それは私には簡単に思えます。 Mara に同意します。

Amita: Azure Artifacts とは

アンディ： Azure Artifacts は、コードベースの依存関係を管理できる Azure DevOps 組織のリポジトリです。 Azure Artifacts では、成果物とバイナリを格納できます。 依存関係のグループに対して、 フィードと呼ばれるコンテナーを提供します。 フィードにアクセスできる開発者は、パッケージを簡単に使用または発行できます。

パッケージを作成してパイプラインで使用するにはどうすればよいですか?

ティム： だから、私が正しいことを理解しているならば、アプリコードはすでにNuGetのパッケージを使用しています。 独自のパッケージを作成し、Azure Artifacts でホストします。 あなたは部品を取り出し、それらがどのように一緒に機能するか説明できますか？ 私はプロセス全体を描くのに苦労しています。

アンディ： もちろん。 パッケージを作成し、Azure DevOps パイプラインで使用するプロセスを見てみましょう。

Andy はホワイトボードに移動します。

パッケージを作成して使用する手順を示すホワイトボード図の図。

パッケージを作成する

まず、Azure Artifacts でプロジェクトを作成します。 Azure DevOps からプロジェクトを作成できます。

次に、パッケージ コードの GitHub リポジトリに接続するパイプラインを Azure Pipelines に作成します。 パイプラインによってコードがビルドされ、パッケージ化され、パッケージが Azure Artifacts にプッシュされます。

作成した Azure Artifacts フィードを指すよう、このパッケージを使用するアプリを更新する必要があります。

その後、アプリを作成するパイプラインを更新します。 この更新により、Azure Artifacts フィードを使用して新しいパッケージの依存関係をプルし、通常どおりにビルドできます。

パッケージを更新する

ティム： 誰かがパッケージを更新した場合はどうしますか?

アンディ： 新しい機能またはバグ修正を使用してパッケージを更新し、テストを実行して正しく動作することを確認する場合は、パッケージのバージョン番号を増やします。 次に、変更をコミットします。 パッケージ パイプラインはコミットを確認し、新しいバージョン番号を使用して Azure Artifacts に新しい成果物を作成します。 バージョン番号が小さい古いパッケージは、そのバージョンに依存するアプリ用に残っています。 このため、通常はパッケージのリストを解除しません。

アプリでは、この新しいバージョンのパッケージを使用する必要がある場合があります。 その場合は、新しいバージョンを参照するようにアプリを更新し、テストをローカルで実行して、この新しいバージョンがアプリで動作することを確認します。 すべてが機能することを満足したら、アプリの変更をパイプラインに送信します。 パッケージの依存関係の新しいバージョンでビルドされます。

Amita: これは良い計画のように聞こえますが、それは他のチームにも役立ちます。 また、先ほどおっしゃっていたコードの "ずれ" も生じません。 これは QA にも役立ちます。

ビルド パイプラインにバージョン管理戦略を含める

ビルド パイプラインを使用する際、パッケージは利用およびテストされる前にバージョンを設定する必要があります。 ただし、パッケージをテストした後でのみ、その品質を知ることができます。 パッケージのバージョンは変更しないでください。そのため、事前に特定のバージョンを選択することは困難になります。

Azure Artifacts は、フィード内の各パッケージに品質レベルを関連付け、プレリリースバージョンとリリース バージョンを区別します。 Azure Artifacts には、パッケージとそのバージョンの一覧に関するさまざまなビューが用意されています。これは、品質レベルに基づいてそれらを分離します。 この方法は、セマンティック バージョン管理に適しています。これは、特定のバージョンの意図を予測するのに役立ちます。 また、Azure Artifacts では、記述子を使用して、Azure Artifacts フィードからより多くのメタデータを含めます。 ビューの一般的な用途は、テスト、検証、またはデプロイされたパッケージ バージョンを共有することですが、パッケージはまだ開発中であり、パブリックに使用する準備ができていません。

既定では、Azure Artifacts のフィードには 3 つの異なるビューがあります。 これらのビューは、新しいフィードが作成された時点で追加されます。 次の 3 つのビューがあります。

  • リリース: @release ビューには、公式リリースと見なされるすべてのパッケージが含まれています。
  • プレリリース: @prerelease ビューには、バージョン番号にラベルがあるすべてのパッケージが含まれています。
  • ローカル: @local ビューには、すべてのリリース パッケージとプレリリース パッケージと、アップストリーム ソースからダウンロードされたパッケージが含まれます。

ビューを使用すると、パッケージ フィード コンシューマーがリリースバージョンとリリースされていないバージョンのパッケージをフィルター処理するのに役立ちます。 ビューを使用すると、コンシューマーは、リリースされたパッケージから選択するか、特定の品質レベルのリリース前にオプトインすることを意識的に決定できます。

Azure Artifacts のパッケージ セキュリティ

パッケージのセキュリティを確保することは、コードの残りの部分のセキュリティを確保するのと同じくらい重要です。 パッケージ のセキュリティの 1 つの側面は、パッケージ フィードへのアクセスをセキュリティで保護することです。 Azure Artifacts の フィードは、パッケージを格納する場所です。 フィードのアクセス許可を設定することで、シナリオに応じて必要な人数のユーザーとパッケージを共有することができます。

フィードのアクセス許可

フィードには、 所有者、 共同作成者、 コラボレーター、閲覧者の 4 つのレベルのアクセス権 があります。 各アクセス レベルには、特定のアクセス許可のセットがあります。 たとえば、所有者は任意の種類の ID (個人、チーム、グループ) を任意のアクセス レベルに追加できます。 既定では、プロジェクト コレクション ビルド サービスはコラボレーターであり、プロジェクト チームは閲覧者です。

セキュリティとライセンスの評価にアクセスするようにパイプラインを構成する

使用するソフトウェア パッケージのセキュリティとライセンスの評価に役立つツールは、サード パーティから入手できます。

これらのツールの一部は、ビルドまたは CD パイプラインに含まれているパッケージをスキャンします。 ビルド プロセス中に、ツールはパッケージをスキャンし、瞬時にフィードバックを提供します。 CD プロセス中に、ツールはビルド成果物を使用し、スキャンを実行します。 このようなツールの 2 つの例は、 Mend Bolt と Black Duck です。 Azure DevOps では、ビルド タスクを使用して、パイプラインにスキャンを組み込みます。