はじめに

この記事は、Microsoft Learn の下記のモジュールの中から重要と思われる内容を(筆者が勝手に抽出して)書き残しているものです。

Create a build pipeline with Azure Pipelines

上記のモジュールは、2020/6/15 現在、英語でのみ提供されています。日本語の内容を確認されたい方は、こちらを参照してください。※公式のものではありません

Azure DevOps - Azure Pipelinesでビルドパイプラインを作成する Part.1

Azure Pipelines とは？

Microsoft Azure Pipelines is a cloud service that you can use to automatically build, test, and deploy your code project.

Microsoft Azure Pipelines は、コードプロジェクトの自動ビルド、テスト、デプロイに利用できるクラウドサービス とあります。つまりCI (継続的インテグレーション)のためのツールの1種ということですね。

Mara: I think that just moving to Azure Pipelines will bring many benefits. Remember, Azure Pipelines is a cloud service. We can use it to automatically build and test code. And it will be available to others as well. It works with just about any language or project type.
(マーラ: Azure Pipelines に移行するだけでも、多くのメリットがあると思います。Azure Pipelines はクラウドサービスであることを忘れないでください。これを使ってコードを自動的にビルドしたり、テストしたりすることができます。そして、それは他の人も利用できるようになります。ほぼすべての言語やプロジェクトの種類に対応しています。)

クラウド、自動ビルド/テスト、みんながそれを利用できる、いろんな言語やプロジェクトの種類に対応している・・・など、DevOps を始める際によく CI/CD ツールの導入を検討している際に、担当者がよく口にするワードですね。そして、(その多くが、CI/CD に興奮している感情だけが先行してしまい) 他人から来る次のような言葉で意気消沈してしまうことが多いと思っています。

Amita: I know it's selfish, but why do I care? One of my big problems is that I never know when a build is ready to test. Sometimes someone remembers to update the spreadsheet, but many times they forget. It seems like I'm the last person to know.

こういう、それは問題じゃないと担当者などから反応があった際に、きちんと返答をできないことが皆さんにもあるのではないかと思います。
ここで思い出したいのは、何のために DevOps をやろうとしているのか、CI/CD ツールを何のために導入するのか、ということです。そうです、以前のモジュール、既存のソフトウェア開発プロセスにアクセスするで言及していた事を思い出してください。現在のプロセスを評価した結果、現在の開発プロセスや CI/CD まわりの状況を理解して、うまく行っていないことに対して改善のために CI/CD ツールを入れるということです。

この Tailspin Web チームについては、ソフトウェア開発にアジャイルなアプローチを選択するの中で、7つの問題を提起しており、その中でも特に3つの問題に取り組む話があったと思います。そのうちの1つが、Stabilize the build server (ビルドサーバーを安定化) です。本モジュールでは、きちんと、現在のプロセスを評価して、出てきたこの課題の解決のために CI/CD ツールである Azure Pipelines を導入するのだと説明していますね。

Our build server has problems. Even keeping it up-to-date is hard. Because Azure Pipelines provides build servers that Microsoft hosts and maintains, it always has the latest patches and security updates. We won't have to worry about maintaining build servers.

ただし、担当者からの質問にもきちんと回答してあげないと、孤軍奮闘で自己満足の DevOps の旅となってしまうので、そこは注意ですね。ここは、製品についてきちんと理解を深めないといけない、ということを物語っていると思います。

Mara: Right, that's something we can easily fix. We can set up the pipeline to notify you automatically, either through email or some other notification, when a build is ready. You'll never have to wait for someone to remind you again.

それは簡単に修正できる、電子メールや他の通知で自動的に通知するようにする、こういった内容は、製品を実際に触ったりリファレンスなどの調査を行わないと、なかなか出てこないと思います。しっかり、Microsoft Learn には演習ステップも組み込まれているので、きちんと実施しましょう。

継続的インテグレーションとは何ですか？

継続的インテグレーション (CI) の定義や意味については、かなり日本の IT 業界にも浸透してきたと思うので、割愛します。※わからない方は、モジュールの説明を参照してください。

ここで注目したいのは、CI のパイプラインを絵で説明している部分です。これはおそらく、自分たちの業務でも利用することがあるでしょうね。CI はわかったけど、具体的に内側ではどういう風に動くのか？ という疑問に答えるために、理解は必要だと思います。

パイプライン全体は、①のタスク (Task) というステップで構成されている。これは、ビルド、テスト、およびデプロイの各ステップの実行方法を定義するスクリプトのようなものである。
パイプラインは、②のようなコード変更が送信 (Push) されたときに実行される。設定は自動あるいは手動が選択できる。パイプラインは、GitHub、Bitbucket、Subversion などのソースリポジトリに接続して使う必要がある。
パイプラインは、③にあるビルドエージェントによって実行され、ビルドやデプロイが行われる。ビルドエージェントは、1つ以上のビルド、またはデプロイメントのジョブを実行するインストール可能なソフトウェアである。
パイプラインの最終成果物は、④のビルド成果物(アーティファクト)である。アーティファクトとは、アプリのテストやデプロイに必要な最小のコンパイル済みユニットのことである。例えば、.jarや.zipなどでパッケージかされた Java/.NET アプリケーション、C++ や JavaScript のライブラリ、仮想マシン (VM) や Docker イメージなど。

ということです。このパイプラインの図の中にあるタスク (Build、Test、Verify など) は、それぞれの環境によって登場するものやその実行の順番は異なると思いますが、こういった形で図で書いて説明・理解するということは、非常に重要だと思います。

モジュールの途中では、パイプラインに関連する以下の内容について、詳細な説明を行っています。ここでは割愛しますが、興味がある方は、確認してみてください。

ビルドエージェント
ホスト型エージェントとプライベートエージェントの実装の違い
エージェントプール
エージェントキュー
サードパーティのシステムと統合するためのサービスエンドポイント
同時並行パイプライン

演習１

ここでは、実際に以下の作業を行っています。

Visual Studio Code の準備する
Git を設定する
ソースコードを取得する
Webアプリケーションをビルドして実行し、動作確認を行う

ここは次にある演習２のための準備となっています。日本語訳した記事を順に実施してもらえればと思います。特に難しいことはありませんが、GitHub の利用が前提になるため、まだアカウントを作成していない人はこちらからアカウントを作成してください。

ビルド作業を計画する

ここで注目したいのは、以下の部分です。

Before she can do that, she needs to think about the existing build scripts. Follow along as she maps the existing scripts to Azure Pipelines tasks.

つまり、既存のビルドスクリプトなどがあればきちんと確認しよう ということです。これは QA エンジニアや運用担当の方が所有している可能性がありますが、無視されることが多いということです。DevOps を推進しようとする人は皆、(マーラのように)運用担当や QA エンジニアではありません。
こういった方々に既存のビルドはどういう風に行なっているか、ビルドスクリプトはもらえるかといった相談をせずに、自分の想像でビルドパイプラインを組んでしまうことがよく見かけられます。これは作業の無駄につながります。パイプラインを構築する前に、その作業に無駄が生まれないようにしっかり確認しましょう、ということですね。

スクリプトコマンドを Azure Pipelines タスクにマッピング

マッピングについては、モジュール内で以下のように、紹介が行われています。

Script command	Azure Pipelines task	Azure Pipelines task (ショートカット版)
`npm install`	`Npm@1`	`Npm@1`
`node-sass`	`CmdLine@2`	`script`
`gulp`	`gulp@1`	`gulp@1`
echo `date`	`CmdLine@2`	`script`
`dotnet restore`	`DotNetCoreCLI@2`	`DotNetCoreCLI@2`
`dotnet build`	`DotNetCoreCLI@2`	`DotNetCoreCLI@2`
`dotnet publish`	`DotNetCoreCLI@2`	`DotNetCoreCLI@2`

Azure Pipelines のパイプラインタスクは YAML で記載されます。このあたりの詳細については、モジュールの最後に紹介されている、Azure Pipelines YAML schema reference を参照してください。※2020/6/15 現在、英語での表記のみになります。

演習２

ここでは、実際に以下の作業を行っています。ここが今回のメインどころです。長い演習になりますが、日本語訳した記事を順に実施してもらえればと思います。

Azure DevOps プロジェクトを取得する
ワークアイテムを実行中に移動する
パイプラインを作成する
パイプラインの実行を見る
ビルドタスクを追加する
ビルドをパイプラインに公開する
読みやすさを向上させる変数を定義する
テンプレートを使用して複数の構成を構築する
テンプレートを定義する
パイプラインからテンプレートを呼び出す
パイプラインを実行する
ブランチを master にマージする
作業項目を完了に移動する
パイプラインを無効にするかプロジェクトを削除する

ここで注目したいのが、ワークアイテムを実行中に移動するとビルドタスクを追加するの部分です。Azure Boards と Azure Pipelines の関係について、(モジュール内に記載はありませんが、) 通例、Azure Boards 上の 1 ワークアイテムとGit リポジトリのブランチは 1 対 1 の関係になることが多いです。この例でも、途中からbuild-pipelineという新しいブランチを作成して、作業を行なっていきます。

何故こういう事を行うかというと、モジュール内でも説明があるように、

The branch gives you a place to experiment and get your build working completely without affecting the rest of the team.

ブランチを切る事で、チームの他のメンバーや本番の環境などに影響を与えることなく、実験を行い、ビルドを完全に機能させることができるからです。masterやfeature、devなど、実運用環境になると、さまざまなブランチにそれぞれのパイプラインが紐付き、実行されることになります。そのまま使って影響を出してはマズいので、今回のスプリントで対応する作業項目(ワークアイテム)に紐づくブランチをきちんと作って、他に影響を与える事なく、作業を進めましょう、という事です。

また、最後の演習であるパイプラインを無効にするかプロジェクトを削除するは必ず実行しましょう。今回、演習内でフォークしたリポジトリは、今後のモジュールでも共通で使うものになります。パイプラインはブランチに紐づきます。最低でもパイプラインを無効化にしておかないと、今後の演習でリポジトリにコードを送信 (Push) するたびに、今回作ったパイプラインも実行されてしまい、無料枠の中で Azure Pipelines が使えなくなります。(つまり、ビルドが止まります。)
それは困るので、しっかり対応しておきましょう。

さいごに

Azure Pipelines は、コードプロジェクトの自動ビルド、テスト、デプロイに利用できるクラウドサービスです。今回は、その中の自動ビルドについて見てきました。
ただ、単純に自動ビルドの環境を作るのではなく、なぜ CI を導入するのか既存プロセスを振り返ることや、既存のビルドスクリプトなどの見直しを行いましょうという内容もありました。

実際に動くものを作るようになったり、新しいこの Azure Pipelines を触り始めると、楽しくて上記のようなことを見逃してしまうことは大いにあると思います。私も経験しました。
ですが、実際にこれを活用する場面は、実運用の場である ということを忘れないでください。これを忘れさえしなければ、みなさん、気持ちよく CI を現場で使いこなすことができると思います。