Azure DevOps Pipelines(パイプライン)の超概要

Azure DevOps全体の概要については、こちらをご覧ください。
https://qiita.com/mstakaha1113/items/1cf45a5119e1397d0315

"Pipelines(パイプライン)"は、生産物を成果に変換するサービスです。
DevOpsを実施するなら要となるサービスですし、アジャイル開発を支えるテクノロジーでありウォーターフォール開発であってもぜひご利用いただきたいサービスです。
サービスとして何があるのかご紹介します。
超概要なので、具体的な画面の説明はありません。

"Pipelines" のメニュー

かなりザックリした説明になります。あえて抽象的な言葉で説明しています。

• Builds : デスクトップアプリケーションならexeを作るまでの作業です。Javaアプリケーションなら例えばjarファイルに梱包するまでの作業です。PCを準備して必要なライブラリをインストールし、ソースコードを持ってきてビルドします。必須ではありませんが（DevOpsでは本来必須ですが）、ここで単体テストや結合テストも自動化して実施します。
• Releases : デスクトップアプリケーションならインストーラー作成およびインストール、JavaのWebアプリケーションならWebサーバーを準備してミドルウェアをインストールしてjarファイルを展開するまでの作業です。Azureですと例えばWeb AppsというPaaSのWebサービスを作成し、そこにBuildsで作成した生成物を展開する作業を実施します。
• Library : アプリケーションを展開していく際に、必要だけど色々な人に見られたら困る値というのがあると思います。そのような値をここに登録していきます。
• Task groups : BuildsやReleasesは、現実問題として何度も同じ設定を書き込むことが多くあります。例えば開発と検証と本番という環境に対してデプロイ先は異なるけど実施する作業は同じというような状況です。このようなタスクは何度も同じ設定をしなければならないという問題もありますが、それ以上に変更が入った際に同様のタスクに対して展開漏れが起こるという問題があります。このような問題を回避するため、そのようなタスクをTask groupsに登録して、これを全環境で使いまわします。Task groups上のタスクへの変更は、それを利用しているすべてのBuildsやReleasesに適用されます。（が、最初から使うことは少ないと思います。）
• Deployment groups : Releasesの展開先が複数存在する場合(例えば複数のVirtual Machine)に、それらを１つのグループとして登録しておく機能です。Releasesでは、ここで登録したデプロイメントグループに対してのリリースタスクを一括実行させることができます。（が、あまり使う機会はないと思います。）

Pipelinesの機能は大きく分けて２つ、CI(継続的インテグレーション)とCD(継続的デリバリー)

Pipelinesは、いわゆるビルド職人やデプロイ職人、マニュアル作業の自動化とお考え下さい。
システム開発をしていると、以下のようなことが起こります。

• わたしのパソコンではビルドできる
• リリースが近づくバタバタしたときに限ってビルド専用PCが壊れる
• Aさんがいないとどのライブラリを使うのかわからない
• マニュアル通りにやってもうまくいかないがBさんが夜中にデプロイするとキレイに本番リリースできる
• 新人がマニュアル通りにデプロイするという慣例がある

これらは概ね不必要なコストや管理できるリスクです。
必要な時に最新の環境でビルドしてテストして利用可能であることが証明されるとしたらいかがでしょうか？それも毎日。
誰も冷や汗をかくことなく、適切なタイミングで適切な機能を本番リリースできたらいかがでしょうか？それもなんだったら毎日。
このようなことを実施するのが継続的インテグレーション(CI : Continues Integration)と継続的デリバリー(CD : Continues Delivery)です。

CI : Continues Integration

必要とあればソースコードがリポジトリに反映される度に、そのソースコードの確からしさを機械的に確認するのがCIです。
Azure DevOps のPipelinesではBuildsが担当します。
登録されたパイプラインを"Build Pipeline"と呼びます。
CIでは、主にビルドとテストを実施します。ビルドするためには対象となる環境が必要ですので、環境準備をします。
ビルドすればコンパイル時のアラートやエラーを検知できます。また自動化されたテストを準備していれば、ここで実施が可能です。

CD : Continues Delivery

コンパイルしテストが終わっている"機械的には文句のつけようが無い"生産物を、実際に稼働する環境にデプロイ（配置）するのがCDです。
Azure DevOps のPipelinesではReleasesが担当します。
登録されたパイプラインを"Release Pipeline"と呼びます。
CDでは、主にデプロイを実施します。デプロイするため、必要に応じてデプロイ先の環境を構築します。
デプロイしてしまえば、その環境を使って例えば人間が受け入れテストを実施することができます。また場合によっては負荷テストの実施が可能です。

まとめ

Pipelinesをうまく利用することで、いつも正しく動作するものを具体的に作成する、いつも正しく動作する環境を具体的に作成することができます。
要不要にかかわらず、これが存在することは大切です。チカラを発揮するのは問題が起きた時です。問題が起きた時、昨日組み込んじゃった問題であればエンジニアの記憶にある内容ですし、その問題に引きずられるソースコードも少なくて済みます。
結果としてエンジニアもマネージャーもユーザー(プロダクトオーナー)もエンドユーザーもハッピーになります。