まとめ

• Jenkinsはjob単位でしかノードに割り振れない
  • 複数ノードで分散ビルドするには設定を駆使する必要がある
  • 結果としてjobの数が増えて管理コストが増大する
• Workflow Pluginで大幅に改善する
  • スクリプトからノードを指定してコマンドを実行できる
  • 複数のjobを組み合わせていたのが一つのスクリプトですむ
  • スクリプトをVCSに入れればビルド設定のバージョン管理も可能

複数ノードをコントロールするのは難しい

Jenkinsを一つのノードで運用している場合はそれほど問題になりませんが、
複数のノードで、jobの一部の部分だけを別のノードで実行するなど、
ある程度複雑な分散をやろうとすると、Jenkins本体の機能では不足してきます。

このような問題に対して、これまではBuild Flow Pluginを使う事で解決が可能でしたが、
Workflow Pluginを使う事で、さらに簡単に解決することが出来ます。

Build Flow Pluginの問題点

Build Flow Pluginは基本的に複数の下流ビルドを管理するために作られているため、
処理を分けようとするとjobの数が増加していきます。

例えばネイティブアプリのビルドのようなCPUパワーを使う処理と、パワーを使わないアップロード処理がある場合、
一つのノードで全てやるよりも、非力なサーバを確保してアップロード処理をそちらで実行した方が、
ビルド用のノードはビルドに専念でき、無駄なくjobを実行できます。
(また、masterとビルドを同じノードでやるとJenkins本体の処理が遅くなるため、分割する利点は他にもあります)

(上段のup#4はup#3の間違いです…)

ビルドが数十分、数時間かかるような巨大な処理の場合、
処理を分散することで稼げる時間はかなりのものになります。

従来では分割する作業を別のjobにし、かつBuild Flow Plugin用のjobを作る必要があります。
さらに、ファイルの受け渡しもできないため、成果物として保存して、
次のjobは前のjobの特定のビルド番号の成果物を取り出す…といった風になります。

jobの数が増えると管理も大変ですし、使う方もどれを使えば良いのか解らなくなります。
ここで、Workflow Pluginを使うことで大きく改善することが出来ます。

Workflow Pluginを使ったビルド

Workflow Pluginでは、slaveを選択してコマンドを実行、
特定のファイルを別のslaveにコピーして処理を実行ということががスクリプトで書けます。

例えば以下のように書くことで、masterでファイルを生成してslaveで実行、
その後結果をmasterにコピーしてアップロードみたいな事が出来ます。

node("master"){
  sh "rake config"
  archive "config.yml"
}

node("slave"){
  unarchive mapping: ['config.yml' : './']
  sh "rake build"
  archive "result.zip"
}

node("master"){
  unarchive mapping: ['result.zip' : '.']
  sh "rake upload"
}

また、複数平行してのビルド等も出来るため、Jenkinsで複数ノードを使って分散ビルドをしたい場合に、
一つのスクリプトで全てをコントロールできるため、とても重宝します。