【ASP.NET Core】Azure Pipelines でコンティニュアスにインテグレーションしてみる その1
はじめに
※ 2019/01/12 更新
Azure Pipeline → Azure Pipelines に修正しました。
以前 Unity のビルドを Azure Pipelines でしてみようと試みたわけですが、今の PC 一台体制では難しそう、ということで、題材を変えて ASP.NET Core で試してみることにします。
というお話。
今回はとりあえずプロジェクト作ってみるのと、 Build pipeline( azure-pipeline.yml )を追っかけてみることにします。
準備
まずは空でプロジェクトを作成して、 GitHub にリポジトリを作っちゃいますよ。
https://github.com/masanori840816/AzurePipelineSample
で、 Azure DevOps( https://dev.azure.com/ユーザー名 )を開いて、プロジェクトを作ります。
Pipelines > Builds > New Pipeline で新しく Pipeline を作ります。
テンプレートは ASP.NET Core のものがあるのでそれを選択し、あとはデフォルトで進めます。
で、出来上がった azure-pipeline.yml はこんな感じ。
azure-pipeline.yml
# ASP.NET Core # Build and test ASP.NET Core projects targeting .NET Core. # Add steps that run tests, create a NuGet package, deploy, and more: # https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core trigger: - master pool: vmImage: 'Ubuntu-16.04' variables: buildConfiguration: 'Release' steps: - script: dotnet build --configuration $(buildConfiguration) displayName: 'dotnet build $(buildConfiguration)'
ほとんど空っぽなのでビルドも問題なく通りますね。
Azure Pipelines 完全に理解した
yaml について
では、生成された yaml を見てみることにします。
trigger
自動で後述の steps の処理(今回は dotnet build )を実行するブランチを指定します。
対象ブランチで変更が Push されると steps が実行されます。
デフォルトでは master のみで、ワイルドカードも使用できるため、下記のように書くと全ブランチが処理の対象となります。
trigger: - *
また開発者が複数いて、同時にビルドが実行されうる場合などは batch を true にすると処理を一つずつ順番に実行してくれるようです。
trigger: batch: true branches: include: - master
- batch を指定する場合、ブランチの指定は branches > include で行う必要があります(エラーになるため)。
- 今回は使っていませんが、除外するブランチを明示する場合、 exclude を使用します。
pool
後述の steps を実行する(つまりビルドを実行する) Agent です。
ここでは Ubuntu16.04 の VM イメージが指定されています。
variables
文字通り「変数」で、 変数名:値 の組み合わせになっており、 $(変数名) で使うことができます。
steps
trigger が引かれた場合(今回は master ブランチに変更が Push された場合)に実行する処理を指定します。
ここでは dotnet build --configuration Release というコマンドが実行されることになります。
steps で実行できる処理はビルドだけではなく、また複数指定することもできます。
下記のようにするとビルド実行後に CmdLine で「hello world」と出力されます。
steps: - script: dotnet build --configuration $(buildConfiguration) displayName: 'dotnet build $(buildConfiguration)' - script: echo hello world
script > displayName
script で実行するコマンドを指定するわけですが、この時 displayName を使うことで独立したものとして結果を見ることができるようになります。
その他
他にもいろいろ指定できるようなので、気になったものを挙げてみます。
pr
steps の処理は、 Pull request を受けた場合も実行されますが、これを特定のブランチに限定したい場合に指定します。
pr: - master
上記のようにすると、 master ブランチに対してのみ処理が実行され、他のブランチが Pull Request を受けた場合は実行されない、という状態になります。
jobs
ビルドなど複数のジョブを登録するときに使います。
jobs: - job: Build steps: - script: dotnet build --configuration $(buildConfiguration) displayName: 'dotnet build $(buildConfiguration)' pool: vmImage: 'Ubuntu-16.04' - job: Message steps: - script: echo hello world
この内容だと前述した steps に script を複数書くのとあまり変わらないのですが、例えば steps を実行する Agent が異なるジョブを登録したい場合などはこちらを使う必要がありそうです。
なお、jobs を使って複数のジョブを登録すると、それぞれのジョブは独立したものとして実行されます。
注意点として、実行するジョブの内 1 つが失敗していても、他 (最後?) のジョブが成功していると Succeeded とメールが来てしまうことです(´・ω・`)
template
jobs や steps などをテンプレートとして、別ファイルに分けることができます。
azure-pipelines.yml
jobs: - template: build_jobs.yml parameters: buildConfiguration: $(buildConfiguration)
build_jobs.yml
parameters: buildConfiguration: '' jobs: - job: Build steps: - script: dotnet build --configuration ${{ parameters.buildConfiguration }} displayName: 'dotnet build ${{ parameters.buildConfiguration }}' - script: dotnet test displayName: 'dotnet test' - script: echo hello world after build pool: vmImage: 'Ubuntu-16.04'
- parameters として呼び出し元から値を渡すことができます。
- jobs なら 呼び出し元、テンプレートともに jobs と内容をそろえる必要があり、 jobs - steps などになっているとエラーが発生します。
特にジョブが多い場合などは便利な気がしますが、 dev.azure.com 上で yaml として編集できるのは azure-pipelines.yml だけのようなので、複数プロジェクトで共有、とかでなければひとまとめにするのが良さそうです。
他パラレルに実行したり、というのも気になるところですが、今回はスキップします。
長くなってきたので一旦区切ります。
(タイミング的に別の記事を差しはさむかもですが)
参照
- Building multiple branches - Azure Pipelines | Microsoft Docs
- Build pipeline triggers - Azure Pipelines | Microsoft Docs
- Create your first pipeline - Azure Pipelines | Microsoft Docs
- Build and Release Agents - Azure Pipelines | Microsoft Docs
- YAML schema - Azure Pipelines | Microsoft Docs
- Predefined build variables - Azure Pipelines | Microsoft Docs
- MkDocsとAzure DevOpsでCI/CD環境を整える - Qiita