Jenkinsのビルドパイプライン系plugin3種比較

Jenkinsのビルドパイプライン系plugin3種類を見ていきます。

ちなみにこれらプラグインはここから適当に探しまんた。

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

ちなみに、ビルドパイプラインって何?

例えば、あるソフトウェアをデリバリーする際、

  1. プロダクションコードをビルドして、
  2. 実行環境に送り込んで、
  3. その上でアプリケーションを再起動して、
  4. テストする

とか一般的だと思うのですが、その一連のジョブ動作をビルドパイプラインといいます。(たぶん)

ここではある特定目的をもった一連のジョブ連鎖の塊と認識してもらってOKです。

特定単一のルートジョブから複数の子孫ジョブが連鎖して起動して1つのビルドパイプラインを形成するのが典型的です。

ちなみに私は30-40個ぐらいジョブがくっついているビルドパイプラインを作ったことがあります。社会の要請に応えた結果だからしょうがないね。

※ビルドジョブは基本バラしましょう。バラして不都合があったらくっつけましょう。

今回使うビルドパイプラインのサンプルジョブについて説明

今回は以下の4種類のジョブを説明のために定義しています。

  • A
    • B (depends on A)
    • C (depends on A)
      • D (depends on A and B)

タイトルどおり、BとCはAの終了後同時に起動し、Dはその両方が終わった時に起動するという設定です。

BとCが両方終わった時のDの起動については Join Plugin - Jenkins - Jenkins Wiki を使ったり使ってなかったりします。

Build Pipeline Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

f:id:knjname:20140506191038p:plain

オーソドックスなビルドパイプラインプラグイン。雑誌などでJenkinsの紹介記事を見る人がおそらくいちばん目にしてそうなプラグイン

基本的に各ジョブが持っている下流ビルド(このビルド後に次のジョブを起動する)、上流ビルドを表示するだけのプラグインです。

使用時には下流ジョブをたどるためのルートジョブを一つ指定して使います。

ただのビューなので、特にビルドの能力や可能性を上げるわけではありません。どのビルドの後に何が起動するのか常に表示されて分かりやすいだけです。

大概の用途にピッタリだと思います。

ただジョブ一つ一つに上流下流設定するのは面倒ですね。クリックゲーになりがち。

Build Flow Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin

f:id:knjname:20140506193902p:plain

Build Pipeline Pluginの自由度の低さに不満を持った人用プラグイン

あちらとは違い、Build Flow Plugin専用ジョブを作成し、そこにGroovyによるDSLでビルドのフローを定義します。

Build Flow Pluginと違って、ビルドの順番や条件がいろんなジョブに分散してとっちらからず*1、便利なDSLで思ったようなパイプライン作成ができたりします。

しかしこの動的な自由度の代償に欠点がいくつかあります。

  • 実際にビルドパイプラインを動かすまで、何がどう連携して動くかは見ることはできません。(まあDSLの機能削れば予測可能なビルドフローDSLっていうのも論理的には作れますけどね。)
  • パイプラインの途中からやり直すことができない。稀によくパイプラインの途中で失敗する場合、時間をおいてパイプラインの途中からジョブをやり直したいことがあります。普通の上流・下流ビルドの起動構成だとこの類のリトライ操作は可能ですが、このプラグインでビルドフローを定義している場合は最初からのやり直ししかできません。
  • ジョブをリネームしても追随しない。

ビルドパイプラインが動いた後のジョブフローは Build Graph View Plugin で見ることが可能です。

f:id:knjname:20140506194010p:plain

ちなみにフロー上の起動ジョブ内で独自に下流ジョブの起動を持っていると、Build Flow Pluginのジョブ起動とは別にそこで新規下流ジョブの起動が始まってしまうので、このプラグインで扱うジョブについては一切下流ジョブの起動設定を持たせないほうがいいでしょう。(プラグインが配慮してジョブの起動をとめてくれたりは一切しません。)

下記画像は試しにBuild Flow Pluginとは別にジョブA内でジョブDを下流ビルドとして起動したみた画像です。きっちり起動しちゃってるのが分かります。

f:id:knjname:20140506194357p:plain

Delivery Pipeline Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Delivery+Pipeline+Plugin

後発のプラグイン。基本的には Build Pipeline Pluginと発想は似ています。

ジョブフローはジョブごとに設定をして、それをどう表示するかだけしか扱わないビュー型のプラグインです。

ジョブごとにジョブのカテゴリ(Stage Name)、ジョブのタスク名(Task Name)を設定し、そのカテゴリごとにジョブを整理して表示してくれます。

百聞は一見にしかず、画像を見たほうがはやいでしょう。

まず、このプラグインをインストールすると毎回ジョブの設定画面の上部に Delivery Pipeline configurationと出てきてウザいことこの上ないですが、各ジョブごとStage Name、Task Nameを設定します。(画像上のジョブの並びが滅茶苦茶ですが気にしないでください)

f:id:knjname:20140506201311p:plain

次に新規ビュー作成でDelivery Pipeline Viewを選んでビューを作成し、PipelinesのComponentsに適当にInitial Jobを選んで追加してあげると、次のように表示されます。

f:id:knjname:20140506201643p:plain

先ほど設定したカテゴリ(Stage Name)ごとにジョブが並んでおり、そのジョブの名前もタスク名(Task Name)になっているのがわかるでしょうか?

非常に説明的でわかりやすいですね。

また、いろんなビルドパイプラインを1ページに収めることができます。

私みたいにパイプラインに大量にジョブを抱えている人はBuild Pipeline Pluginよりこっちのほうが見やすくていいかもしれません。

まとめ

  • 普通の用途にはBuild Pipeline PluginかDelivery Pipeline Pluginが最適でしょう。
  • どうしてもそれじゃやってられない人はデメリットをのんで、Build Flow Pluginを使いましょう。

*1:ただ、ビルドフローがとっちらかないといっても上流ビルド成果物のコピーとかは個々ジョブ内で定義するしかありません。