パイプライン・アーキテクチャ
パイプラインは、GitLabにおけるCI/CDの基本的な構成要素です。 このページでは、パイプラインに関連する重要な概念を説明します。
パイプラインを構成する方法は主に3つあり、それぞれに利点があります。 これらの方法は必要に応じて組み合わせることができます。
- Basic: すべての設定がわかりやすい場所にある、単純なプロジェクトに適しています。
- Directed Acyclic Graph:効率的な実行を必要とする大規模で複雑なプロジェクトに適しています。
- 子/親パイプライン:モノレポや、独立して定義されたコンポーネントが多数あるプロジェクトに適しています。
以下に使用されているキーワードの詳細については、CI YAMLのリファレンスをご確認ください。
基本的なパイプライン
これは、GitLabで最もシンプルなパイプラインです。 ビルドステージのすべてを同時に実行し、それらがすべて終了するとテストステージのすべてを同じように実行します。 最も効率的とは言えず、ステップ数が多いとかなり複雑になりますが、メンテナンスは容易です。
/.gitlab-ci.yml
パイプラインの基本構成例:
stages:
- build
- test
- deploy
image: alpine
build_a:
stage: build
script:
- echo "This job builds something."
build_b:
stage: build
script:
- echo "This job builds something else."
test_a:
stage: test
script:
- echo "This job tests something. It will only run when all jobs in the"
- echo "build stage are complete."
test_b:
stage: test
script:
- echo "This job tests something else. It will only run when all jobs in the"
- echo "build stage are complete too. It will start at about the same time as test_a."
deploy_a:
stage: deploy
script:
- echo "This job deploys something. It will only run when all jobs in the"
- echo "test stage complete."
deploy_b:
stage: deploy
script:
- echo "This job deploys something else. It will only run when all jobs in the"
- echo "test stage complete. It will start at about the same time as deploy_a."
有向非環状グラフのパイプライン
効率を重視し、すべてをできるだけ早く実行したい場合は、有効非巡回グラフ(DAG)を使用します。needs
キーワードを使用して、ジョブ間の依存関係を定義します。 GitLab がジョブ間の関係を把握していれば、すべてをできるだけ早く実行することができ、可能な場合は後続ステージにスキップすることもできます。
下の例では、build_a
とtest_a
がbuild_b
とtest_b
よりもずっと速い場合、build_b
がまだ実行中であっても GitLab はdeploy_a
を開始します。
DAG の例/.gitlab-ci.yml
図に一致する構成:
stages:
- build
- test
- deploy
image: alpine
build_a:
stage: build
script:
- echo "This job builds something quickly."
build_b:
stage: build
script:
- echo "This job builds something else slowly."
test_a:
stage: test
needs: [build_a]
script:
- echo "This test job will start as soon as build_a finishes."
- echo "It will not wait for build_b, or other jobs in the build stage, to finish."
test_b:
stage: test
needs: [build_b]
script:
- echo "This test job will start as soon as build_b finishes."
- echo "It will not wait for other jobs in the build stage to finish."
deploy_a:
stage: deploy
needs: [test_a]
script:
- echo "Since build_a and test_a run quickly, this deploy job can run much earlier."
- echo "It does not need to wait for build_b or test_b."
deploy_b:
stage: deploy
needs: [test_b]
script:
- echo "Since build_b and test_b run slowly, this deploy job will run much later."
子と親のパイプライン
上の例では、2つのタイプのものが独立して構築されていることがわかります。 これは、trigger
キーワードを使って、子/親パイプライン) を使うのに理想的なケースです。 これは、設定を複数のファイルに分離し、物事をとてもシンプルに保ちます。 また、これと組み合わせることもできます:
-
rules
キーワード: 例えば、その領域に変更があったときだけ、子パイプラインがトリガーされるようにします。 -
include
keyword: 共通の行動を取り入れることで、同じことを繰り返さないようにします。 - DAGパイプラインを子パイプラインの内側に配置することで、両者のメリットを実現しています。
例/.gitlab-ci.yml
ダイアグラムに一致する親パイプラインのコンフィギュレーション:
stages:
- triggers
trigger_a:
stage: triggers
trigger:
include: a/.gitlab-ci.yml
rules:
- changes:
- a/*
trigger_b:
stage: triggers
trigger:
include: b/.gitlab-ci.yml
rules:
- changes:
- b/*
DAGneeds:
キーワードを使用した、/a/.gitlab-ci.yml
内にある子a
パイプラインの構成例:
stages:
- build
- test
- deploy
image: alpine
build_a:
stage: build
script:
- echo "This job builds something."
test_a:
stage: test
needs: [build_a]
script:
- echo "This job tests something."
deploy_a:
stage: deploy
needs: [test_a]
script:
- echo "This job deploys something."
DAGneeds:
キーワードを使用した、/b/.gitlab-ci.yml
内にある子b
パイプラインの構成例:
stages:
- build
- test
- deploy
image: alpine
build_b:
stage: build
script:
- echo "This job builds something else."
test_b:
stage: test
needs: [build_b]
script:
- echo "This job tests something else."
deploy_b:
stage: deploy
needs: [test_b]
script:
- echo "This job deploys something else."
また、共通のセットアップ手順や最後に統一されたデプロイメントを行う場合など、子パイプラインをトリガーする前または後にジョブを実行するよう設定可能です。