パイプラインステージとは？作業をフェーズにまとめる

パイプラインステージとは、関連するjobをまとめ、通常は前のステージが成功した後に1つの単位として実行する、pipelineの名前付きフェーズです。

ほとんどのpipelineは、順に実行されるいくつかのステージで構成されます。コードをbuildし、testし、そしてdeployする、というものです。ステージはその構造の粗い単位です。まとまるべき1つ以上のjobをまとめ、名前を与え、pipelineが先に進む前に通過しなければならないチェックポイントとして機能します。ステージで考えることで、複雑なpipelineが一目で読めるようになります。

ステージに含まれるもの

ステージは1つ以上のjobを保持します。ステージ内のjobは互いに独立しているため、しばしば並列に実行される一方、ステージ自体は通常は順次実行されます。典型的なレイアウトは、buildステージ、次にtestステージ、次にdeployステージです。

ステージはゲートとして機能する

デフォルトでは、ステージは前のステージが成功して初めて開始します。testステージのいずれかのjobが失敗すると、deployステージは決して実行されません。これによりステージは自然なquality gateとなります。各フェーズが次を守るのです。

ステージ、job、ステップの比較

ステージ: 名前付きのフェーズ、例「test」。
job: ステージ内で1台のマシン上で実行される作業の単位、例「unit-tests」。
ステップ: job内の単一のコマンド、例「run pytest」。

簡単な例

GitLabスタイルの設定では、stages: [build, test, deploy]と書き、各jobにstage:の値を割り当てられます。GitHub Actionsには文字どおりの「stage」キーワードはありませんが、jobとそれらをフェーズに並べるneeds:依存関係で同じ形を構築できます。

なぜステージが速度に重要か

ステージは前のステージを待つため、遅いステージはその後のすべてを遅らせます。独立した作業をステージ内の並列jobに分割すると、そのステージが短くなります。マネージドrunner（Latchkeyなど）では、testステージをより多くのrunnerに分散させることで、pipelineの形を変えずに実時間を短縮できます。

一般的なステージパターン

build/test/deployのほかに、チームはlint、security-scan、package、promoteといったステージを追加します。適切なステージ数は、明快さと各ゲートのオーバーヘッドとのバランスを取ります。ステージが多すぎると待ち時間が増え、少なすぎると何が起きているかが隠れます。

重要なポイント

ステージは、jobをまとめて前のステージの後に実行される名前付きフェーズです。
ステージはquality gateとして機能し、失敗したステージは後続を止めます。
ステージ内のjobはしばしば並列に実行され、ステージ自体は順に実行されます。