vaguely

和歌山に戻りました。ふらふらと色々なものに手を出す毎日。

【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 を使うことで独立したものとして結果を見ることができるようになります。

f:id:mslGt:20181230152238j:plain

その他

他にもいろいろ指定できるようなので、気になったものを挙げてみます。

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 を使って複数のジョブを登録すると、それぞれのジョブは独立したものとして実行されます。

f:id:mslGt:20181230152001j:plain

注意点として、実行するジョブの内 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 だけのようなので、複数プロジェクトで共有、とかでなければひとまとめにするのが良さそうです。

他パラレルに実行したり、というのも気になるところですが、今回はスキップします。

長くなってきたので一旦区切ります。
(タイミング的に別の記事を差しはさむかもですが)

参照