Azure Pipelinseを使ってみた
はじめに
2019年3月時点でのまとめです。
今後の更新は予定していません。
詳細は公式サイトを確認してください。
TLDR;
- アカウントの作成にはLiveアカウントが必要
- オープンソースは10並列まで無料
- GitHub、GitHub Enterprise、Azure Reposからコードを取得可能
- YAMLを利用して柔軟なPipelineを構築可能
事前準備
Azure Pipelinesを利用するためにはAzure Devopsアカウント(Microsoft アカウント)が必要です。
他のCIサービスの多くはGitHubアカウントのみで扱えるので一瞬戸惑いました。
ただよくよく考えると、AWS CodeBuildやCloud Buildと条件は同じなので気にし過ぎなのかもしれません。
構成
Microsoft アカウントを利用してAzure Devopsアカウントにログインすると、新規でOrganizationを作成することができます。(Organizationは複数持つことが可能です)
Organaizationの下に、Projectを作成することができます。
Projectの以下の項目があります。
- Summary
- Dashboards
- Wiki
- Pipelines
PipelinesがAzure Pipelinesのことを指しています。
Pipelineの作成
最初にコードの取得先を選択します。
2019年3月現在以下の選択肢があります。
- Azure Repos
- GitHub
- GitHub Enterprise
Visual Dsignerを利用する場合、以下の選択肢も有るようです。（未確認）
- Bitbucket Cloud
- Subversion
- External Git
また、パイプラインの実行はOSSであれば10並列まで無料となっています。
YAMLの定義について
Pipelinesを構成する要素は大きく2つあります。
- Tasks
- Jobs
taskは予め用意されたよくある処理の定義です。
例えばNode.jsのヴァージョンを指定してインストールしたい場合は以下のtaskを利用することができます
また、自分で新しくtaskを作成することができます。
jobはユーザが独自にbuildやdeploymentの設定を記述することができる機能です。
taskにない操作は必然的に、jobで定義する必要があります。
例えば、Rustのヴァージョンを複数とってClippyを実行するjobは以下のようになります。
Azure Pipelinesで実現できる操作の範囲はとても広く、ここでは紹介しきれません。
そこで、個人的に気になった機能をいくつかピックアップして紹介したいと思います。
Container Image
Azure Piplinesのエージェントに使用するDocker Containerを任意のものに変更することができます。
また、処理ごとに別々のDocker Containerを利用することも可能です。
Dependencies
任意のjobを別のjobに依存させることができます。
CircleCIのWorkflowに近い機能です。
例えば以下のように、 “B” の実行を “A” に依存することが可能です。
The matrix strategy
The matrix strategy を利用することで、複数の言語バージョンに対して同一のstepを適用することができます。
例えば、Node.js v8 / v10に同一のstepを適用したい場合以下のよう記述できます。
Step re-use
jobで実行する具体的な操作はstepで表現できます。
stepは別ファイルに記載することが可能です。
例えば、yarnpkg/berryでは以下のようにUnitテストの処理を外に切り出しています。
紹介した内容を一個のYAMLにまとめると以下のような記述になります。
job間で状態の共有が出来ず、つどyarnを実行しているのが気になりますが、それ以外は拡張性が高く他のCIサービスと一線を画していると思います。
まとめ
既存のCIサービスの不満を上手く解消しているサービスという印象でした。
個人でOSS用に利用する分には、無料で問題なく利用できるため今後自分が管理しているリポジトリはAzure Pipelinesに移行していこうと思います。
