TravisCI を使用した NuGet パッケージの継続的配信

· 2分で読める
.NET NuGet CI/CD
Available in: 日本語 · English · Español · Français · Deutsch · Português · 한국어 · Русский · 中文 · العربية · हिन्दी · Polski · Türkçe · Bahasa Indonesia · Nederlands

最近、master ブランチにプッシュした、またはプッシュしようとしたコードを自動的にテストするツールとして Travis CI を使用する方法に関する チュートリアル を行いました。それをコンパイルしてテストし、最終的にその変更のステータスを報告します。

Gyazo からの画像

しかし、より良い にし続けることはできます。たとえば、最後のチュートリアルで作成されたコア ライブラリを NuGet フィードを使用して公開し、誰もが自分のライブラリで簡単に操作できるようにしたいと考えています。

しかし、どのようにして? そのパッケージをどのようにコンパイル、テストし、フィードに公開して、全員がプロジェクトにダウンロードできるようにするのでしょうか?

さて、これがこのチュートリアルです 😁!

＃ 新着情報？

コードに関してはほとんど変更はありません。変更する必要があるのは、パッキング、公開、そしてそれを自動化する方法です。

.NETコアCLI

.NET Core CLI を使用します。前のチュートリアルでは、dotnet restore、dotnet build、dotnet test などのコマンドで使用しました。

ここで、新しいコマンドのセットを使用してみます。

dotnet nuget

このツール セットのドキュメントは ここ で確認できますが、簡単な説明は次のとおりです。

dotnet nuget は、パッケージのインストール、復元、削除、公開を含む必須ツールのセットです。

NuGet フィード

NuGet は .NET のパッケージ マネージャーです。 NuGet クライアント ツールは、パッケージを作成および使用する機能を提供します。 NuGet ギャラリーは、すべてのパッケージ作成者と利用者が使用する中央のパッケージ リポジトリです。

NuGet は無料なので、サインアップして API キーを取得し、パッケージのアップロードを開始できます。これらはアップロードされ、検証されてから、全員にリストされます。

APIキーを取得する

パッケージをアップロードするには、サインアップ後に API キーを取得する必要があるため、API キー ページ に移動して、新しい API キーを作成します。

Gyazo からの画像

API キーの有効期限は 365 日であることに注意してください。

次に、キーをコピーしてどこかに保存します。ページに記載されているように、再度見ることはできなくなり、保存しなかった場合は再生成する必要があります。

Gyazo からの画像

NuGetパッケージを生成する

API キーを取得したので、次のステップはソリューションから NuGet パッケージを生成することです。クラス ライブラリがあるソリューションを開きます。

最後のチュートリアル のソリューションを使用します。これには、CalculatorCLI.Core という .NET Core ライブラリ クラスがあります。

プロジェクト プロパティ、パッケージに移動すると、パッケージのバージョン、作成者、説明など、パッケージに関する多くの情報が表示されます。

次にこれを入力します。実際にはすべてを入力する必要はありませんが、重要で必須のものは Package id、Package version、Authors、および Description です。また、自分でファイルをアップロードしようとすると、License が要求されるため、それも追加する必要があります。Gyazo からの画像

次に保存し、プロジェクト内で右クリックして Pack を選択します。

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

出力には、すべてが正常であれば Successfully created package が出力されることが示されます。

dotnet を使用する

前のチュートリアルと同様に、ソリューションを構築してテストするためにさまざまなコマンドを使用しました。ここで、パッケージをパックして公開するためのコマンドをさらに追加します。

それらのコマンドは次のとおりです。

  1. dotnet pack -c <configuration>
  2. dotnet nuget push <package> <k <apikey> -s <source>

デプロイメントスクリプト

ビルドの方法を変更する予定であるため、環境に応じて異なるファイルを用意し、それぞれのファイルにビルド定義を含めるのが最善のアイデアであると考えています。

そこで、リポジトリのルートに 3 つの bash スクリプトを含む scripts という名前のフォルダーを作成しましょう。

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

.travis.yml ファイルの改善

ソース コードが更新され、使用する必要があるコマンドがわかったので、継続的デリバリーと継続的インテグレーションを統合する必要があります。これにより、コーディング、テスト、レビュー、プッシュ以外に何もする必要がなくなります。

.travis.yml ファイルに対してこれから行うことは次のとおりです。

  1. 別の stages を追加します
  2. 各 stage はブランチに依存します
  3. ビルドがマスター上にある場合は、パッケージを更新する必要があることを意味するため、パッケージを NuGet フィードにプッシュします。
  4. ビルドがプル リクエストの場合、ビルドがコンパイルおよびテストされるかどうかを確認しますが、公開するつもりはありません。

ステージ

彼らのドキュメントから:

ビルド設定 (.travis.yml ファイル) で条件を指定することで、ビルド、ステージ、ジョブをフィルターで除外したり拒否したりできます。

TravisCI stages に関する詳細は、ドキュメント ページ で見つけることができます。

したがって、ファイルを変更してステージを追加すると、次のようになります。

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

ご覧のとおり、3 つの異なるステージ compile、test、および push があり、最後のステージのみが branch が master の場合に実行され、それに対して pull request ではなく、push のみが実行されます。

これについて理解できない場合は、ドキュメントを参照してください。非常に簡単に説明されています。

それを念頭に置くと、すべての pull request は NuGet フィードに何もプッシュしません。

APIキーを環境変数として設定する

リポジトリ ビルドの設定に移動し、NUGET_API_KEY という名前の新しい環境変数を追加します。値は NuGet ページからコピーした API キーです。

Gyazo からの画像

pull request を作成します

すべての設定が完了したので、pull request を作成し、そのプル リクエストのコンパイルで最後の stage が無視されているかどうかを確認します。

ビルドを確認する

プル リクエストを行うとすぐに、ビルドが TravisCI ダッシュボードのキューに入れられます。ご覧のとおり、そこには 3 つではなく 2 つの異なるビルドがあることがわかります。Gyazo からの画像

ここで pull request を受け入れ、ビルドを再度チェックして、2 つではなく 3 つのジョブがあることを確認しましょう。

Gyazo からの画像

ビルドがキューに入れられていることがわかるとすぐに、最後に Deploy-prod を含む 3 つのジョブが表示されます。

Gyazo からの画像

このビルド全体が完了すると、パッケージがソースにプッシュされたことがログですぐに確認できます。

Gyazo からの画像

そして明らかに、NuGet ページで確認できます。

Gyazo からの画像

Gyazo からの画像

#それだけです

このチュートリアルでは、NuGet パッケージの配信を自動化する方法について学びました。 TravisCI、stages、dotnet nuget などのツールを使用しました。

私の意見では、それが適切に設定するには時間がかかり、場合によっては非常に複雑すぎる可能性があるとしてもです。すべてを完璧かつ自動化するために、この種のテクニックに時間を投資する価値があります。

ソース コードは .travis.yml ファイルで [ここ] (https://github.com/emimontesdeoca/CalculatorCLI-demo) にあります。ご質問がある場合は、私の twitter までお気軽にご連絡ください。