先ごろ、私たちはDeclarative Pipelineのバージョン1.3をリリースしました。これには、シーケンシャルステージのサポートなど、いくつかの重要な新機能が含まれています。シーケンシャルステージ機能を使用すると、1つの並列ブランチに複数のシーケンシャル（順次処理）ステージを追加できます。パイプラインの制御が強化されたことによって、ユーザーは、より多くのユースケースに対して宣言的な構文を利用できるようになります。
シーケンシャルステージ
Declarative 1.2では、Declarative構文の一部として並列実行ステージを定義する機能が追加されました。今度のDeclarative 1.3では、他のステージ内にネストされたステージを指定する方法が追加されました。これは「シーケンシャルステージ」と呼ばれます。
並列ブランチで複数のステージを実行する
よくあるユースケースの1つは、複数のプラットフォームでのビルドおよびテスト実行です。これはparallelステージでも実現できましたが、今回、各parallelブランチで複数のステージを実行できるようになったことで、パイプラインの進行状況の把握が容易になり、ログを確認しなくても、現在どのステップが実行されているかが正確にわかります。
post、when、agentのほか、パイプライン構文リファレンスに記載されているすべてのステージディレクティブをシーケンシャルステージで使用し、各parallelブランチのさまざまな動作を制御することもできます。
以下の例では、WindowsとLinuxの両方でビルドを実行し、ブランチがマスターの場合にだけデプロイします。
pipeline {
agent none
stages {
stage(“build and deploy on Windows and Linux”) {
parallel {
stage(“windows”) {
agent {
label “windows”
}
stages {
stage(“build”) {
steps {
bat “run-build.bat”
}
}
stage(“deploy”) {
when {
branch “master”
}
steps {
bat “run-deploy.bat”
}
}
}
}
stage(“linux”) {
agent {
label “linux”
}
stages {
stage(“build”) {
steps {
sh “./run-build.sh”
}
}
stage(“deploy”) {
when {
branch “master”
}
steps {
sh “./run-deploy.sh”
}
}
}
}
}
}
}
}
同じagent 、environment、またはoptionsを使用して複数のステージを実行する
シーケンシャルステージの機能は、もともとはparallelブランチに複数のステージを持たせたいというユーザーの希望によって実現されましたが、複数のステージを同じagent、environment、whenなどでグループ化できるということは、ほかにもたくさんの使い途があることに私たちは気が付きました。たとえば、パイプラインで複数のエージェントを使用しているが、同じエージェントを使用するステージは必ず同じワークスペースを使用するようにさせたい場合、親のstageにagentディレクティブを付けると、 stagesディレクティブ内のすべてのステージが、同一エグゼキューターの、同一ワークスペース内で実行されます。もう1つ例を挙げると、これまではパイプライン全体または個々のステージに対してしかタイムアウトを設定できませんでしたが、親stageに複数のstageをネストすると、親のoptionsディレクティブでタイムアウトを定義することができ、そのタイムアウトは、ネストされたステージを含む親ステージの実行に適用されます。条件付きで複数のステージの実行を制御することもできます。たとえば、デプロイメントプロセスが複数のステージにまたがっており、特定のブランチの場合にだけ、またはその他の基準が満たされている場合にだけ、これらのステージを実行したいケースなどです。新しいバージョンでは、stagesディレクティブを使って、関連するステージをすべて1つのparentステージにまとめ、親に対して単一のwhen条件を指定できるので、同じwhen条件をいくつものステージにコピーする必要がありません。
私が個人的に便利だと思うユースケースの1つが下の例です。Declarative 1.2.6では、ステージにinputディレクティブが追加されました。これを指定すると、Scripted Pipelineのinputステップを使用してユーザーがパイプラインの継続を確認するまで、パイプラインの実行が一時停止されます。inputディレクティブは、ステージにエージェントが指定されていればステージがエージェントに入る前、そしてステージにwhen条件が指定されていればwhen条件が評価される前に評価されます。しかし、ほとんどのステージでトップレベルのエージェントを使用している場合は、入力を待つ間にもトップレベルのエージェントのエグゼキューターを使用することになります。これはリソースの浪費となります。シーケンシャルステージを使用すると、パイプラインの最上位レベルではagent noneを指定し、inputディレクティブが指定されたステージより前に共通のエージェントを使用して実行されるステージをグループ化して、必要なagentが指定された親stageの下で実行できます。その後、パイプラインがinputステージに達したときには、エージェントのエグゼキューターは使用されません。
pipeline {
agent none
stages {
stage(“build and test the project”) {
agent {
docker “our-build-tools-image”
}
stages {
stage(“build”) {
steps {
sh “./build.sh”
}
}
stage(“test”) {
steps {
sh “./test.sh”
}
}
}
post {
success {
stash name: “artifacts”, includes: “artifacts/**/*”
}
}
}
stage(“deploy the artifacts if a user confirms”) {
input {
message “Should we deploy the project?”
}
agent {
docker “our-deploy-tools-image”
}
steps {
sh “./deploy.sh”
}
}
}
}
これらは、Declarative 1.3の新しいシーケンシャルステージ機能のパワーを示す一例にすぎません。この新機能により、Declarative Pipelineを使用してスムーズに処理できる重要なユースケースが増えます。次回の記事では、もう1つの待望されていた機能、パイプラインのどのステージからでもパイプラインを再起動できる新しい機能について説明します。
Andrew Bayer
CloudBees
（この記事は、CloudBees社 Blog 「What’s New in Declarative Pipeline 1.3: Sequential Stages」2018年7月10日 Andrew Bayer 投稿の翻訳記事です。）