前回は NuGet パッケージの作る際の注意点と手作業での Azure Artifacts への発行をメモしましたが、
今回は Azure Pipelines で CICD します。
公式ドキュメントの左側のメニューで "classic" と記載のある古い時代の Release pipelines ではなく、Multi stage pipelines です。ここ大切。
Multi stage pipeline の基本的な話は昔に触れてるのでリンク張っときます。
本題に戻りますが、前提とやりたいことはこんな感じです。
- GitHub にソースコードがある
- Pull Request に応じて Azure Pipelines で CI する
- GitHub 上でバージョンのタグをつけたら Azure Pipelines で CD (Azure Artifacts へ発行) する
Azure Pipelines でパイプラインの作成
パイプラインを作る
Azure DevOps のポータルで、左側にある Pipelines のアイコンをクリック > Pipelines をクリックします。
Pipelines の画面が表示されます。Pipeline の作成ボタン（初めて作る場合は画面中央に Create Pipeline、以降は、画面右上に New pipeline ボタンがあります。）をクリックします。
Code の選択画面が表示されます。今回は GitHub のコードを使うので、GitHub を選択します。
対象の repository を選択します。
選択すると GitHub の認証が求められます。パスワードを入力して認証が出来たら GitHub の画面が表示されます。内容を確認し、Azure Pipelines の アクセス権限を許可しましょう。画面を下の方に進めると、Approve and install ボタンをクリックします。
Azure DevOps の画面に戻ってきてくれるはずです。Configure your pipeline の画面になるはずです。
📌 私が既に Azure DevOps と GitHub を連携済みの状態なので、そうじゃない場合にどうなるか覚えてないですが、もしかしたらGitHub の Marketplace で Azure Pipelines をインストールする必要があるかもしれません。あと、Azure DevOps の Organization や Project を選択する操作が必要かもしれません。
私の場合、Azure DevOps の画面に戻ったタイミングでなぜか別の Organization にリダイレクトされていまうという闇に遭遇しました（画面開きなおしたら進めた）。
闇に遭遇しなければ、下図のようにテンプレートの選択に遷移します。ちょうどよいものはないので、Starter pipeline を選んでおきます。
Multi stage pipeline の YAML を構成する
パイプラインでやりたいこと
やりたいことの1つは、GitHub から PR 時に CI が動くことです。
PR時に動くってのは、タイミングがとりあえず2つあると思ってます。
- PR が作成されたタイミング（PR作成後、merge される前までに push したタイミングを含む）
- PRが Merge されたタイミング
今回は NuGet パッケージへの発行なので、CD はあまり考えてません。GiHub でバージョンのタグを打ったタイミング（ GitHub の Release を記載したタイミングともいいますかね）でリリースしたいからです。
ということで、作りたい Pipeline は以下にしました。
- master branch に PR が作成された（前述 1 ）時に ビルド・テスト
- 手作業で pipeline が実行されたときもビルド・テスト する
- PRが Merge された（前述 2 ）時は、何もしない
- GitHub 上でタグをつけたときに Azure Artifacts の Feed へ発行
GitHub のバージョンの情報をとってきてライブラリに埋め込むは簡単できそうですが、今回は個人的に興味がないのでやりません。
YAML の定義
こんな感じ。
私個人的な癖としては、stage や job の名前の最後にわざわざ *_stage とか *job とか Suffix 付けてます。ダサいなーと思いつつも以前 condition をたくさん指定するケースの時に suffix が無かったせいでミスったのと、job と stage で名前が被って naming に無駄に悩むことがあったので...。
YAML のざっくりな解説します。
2行目: トリガーの書き方
tags のトリガーの書き方はこちらのドキュメントを確認すればOKです。
17行目: test stage の起動条件
条件には、Pull Request 時と手動にしてます。Build.Reason に関してはこちらのドキュメントに書かれています。
18-29行目: dotnet test
build_test_stage では、dotnet の test コマンドだけ実行してます。 test 時に build 走るので build は省略しがちですが、この考えは良いのかな...とたまに思っています。
31-32行目: Build.Reason: IndividualCI の動作検証
今回は動作的に意味ない stage です。PR の merge 後に condition の設定が正しく動くかだけの確認用に書きました。
42-43行目: 起動条件: タグの検証
この stage は、GitHub で v から始まる tag を登録した時に動作するよう43行目の condition を設定しています。
50-63行目: nuget 発行用の artifact を生成
NuGet のパッケージ化と発行には、NuGetCommand@2 の pack は build が動くはずなんですが、設定がおかしかったときにエラーログ見るのが大変だったので build と pack を分けました。ということで2度ビルドしないよう pack するときに ----no-build オプションが動くよう設定しています(62行目）。
バージョン指定は、私はソースコード側で指定したものを使うので特に設定してませんが、BuildNumber をつけたり色々できます。方法についてはこちらのドキュメントにあります。
Azure Pipelines 上で設定
Azure DevOps の Azure Pipelines から編集すると、 Package task は、Settings をクリックすることで GUI で入力できるのでちょっとわかりやすいですね。もちろんドキュメントでどんなオプションを設定できるのか確認は必要ですが。
これで GitHub で PR 作ってから Azure Artifacts の Feed への発行まで自動化できました。
YAMLの作成はわかると簡単なんですが、パイプラインの作成はプロジェクトの最初にしかしない分頻度が低いし、Azure DevOps は進化が早いので触る度に変わってる印象あります（いいことですね！）。気づいたタイミングでブログにメモしておきたいところです 。
これ使ったプロジェクトはこちら。
ちょっとした Tips
azure-pipelines.yml のパス
とりあえずで sln ファイルと同じパスに azure-pipelines.yml に置いてます。ファイル名を変えたりパスを変えた場合、Pipelines 側でファイルパスを設定する必要があります。設定方法は以前に書いたのでリンクだけはっておきます。
Azure Pipelines で パイプライン作成時に警告が出る
ソースコードが GitHub: public, パイプラインには Azure DevOps: private を使ってるいるせいか、パイプラインの作成時にこんな警告が出てました。
You selected a public repository, but this is not a public project. Go to project settings to change the visibility of the project. Learn more
私の場合、結局なにも設定せずに正常に動いていますが、だめなケースあるのかなと気になります。警告文の最後にあるリンクは、Organization の Security policies で public project を allow してねって内容です。ちなみにそこは私のは on にしてるので、Off の時あかんくなるのかなと思ったり（ 私が Off にすることはないので試してない）。
