Azure Artifacts とは何ですか?
このユニットでは、Azure Artifacts を使用して、アプリで使用できるパッケージを安全に作成し管理する方法について簡単に説明します。
Azure Artifacts が .NET パッケージをホストする適切な方法であるかどうかを判断する際、チームにもう一度確認してみましょう。
Mara: 私たちにとっては、新しい Models パッケージを Azure Artifacts でホストするのが妥当かと思います。 私たちは既に Microsoft Azure DevOps 組織に属しているので、その方が、別のパッケージ マネージャー上で設定するよりも、認証を容易に行えます。
Andy: ミーティングの前に詳しく調べましたが、迷いはありません。 Mara の意見に賛成です。
Amita: Azure Artifacts とは何ですか?
Andy: Azure Artifacts は、Azure DevOps 組織において、コードベースの依存関係を管理することができるリポジトリです。 Azure Artifacts には、成果物やバイナリを格納することができます。 一連の依存関係を集めた "フィード" と呼ばれるコンテナーが備わっています。 フィードにアクセスできる開発者は、パッケージを簡単に利用したり発行したりすることができます。
パッケージの作成方法とパイプラインにおけるその使い方を教えてください
Tim: 私の理解では、すでにアプリケーション コードには NuGet からのパッケージを使用しています。 私たちは独自のパッケージを作成し、それを Azure Artifacts でホストしようとしています。 個々の要素を挙げて、それらがどう連携するのか、概要を示してもらえますか。 プロセスの全体像をなかなか描けずにいます。
Andy: もちろん。 パッケージを作成して、それを Azure DevOps パイプラインで使用するプロセスについて考えてみましょう。
"Andy は、ホワイトボードに移動します"。
パッケージを作成する
まず、Azure Artifacts でプロジェクトを作成する必要があります。 
これは Azure DevOps から行うことができます。
次に、パッケージ コード用の GitHub リポジトリに接続する Azure Pipelines にパイプラインを作成します。 そのパイプラインは、コードをビルドしてパッケージ化し、Azure Artifacts にそのパッケージをプッシュします。 
このパッケージを利用するアプリケーションは、今後、作成した Azure Artifacts フィードを参照するように更新する必要があります。 
その後、アプリケーションを作成するパイプラインを更新します。 更新することで、Azure Artifacts フィードを使用して新しいパッケージの依存関係をプルし、通常どおりにビルドすることができます。 
パッケージを更新する
Tim: だれかがパッケージを更新した場合はどうなりますか?
Andy: 新機能またはバグ修正でパッケージを更新した後、正しく動作することを確認するためのテストを実行する際に、パッケージのバージョン番号を繰り上げます。 ここで、次のようにして変更をコミットします。 パッケージ パイプラインがそのコミットを検出し、新しい成果物を新しいバージョン番号で 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 では、ビルド タスクを使用して、パイプラインにスキャンを組み込むことができます。