2022/05/20 GitLabのデモ動画を作りました！このブログの末尾にリンクを張ったのでよろしければご視聴ください。
2022/08/23 一部の図の背景が透過されていて見づらかったので、修正致しました。
皆様こんにちは。SEの小池と申します。
実際にアプリケーションの開発経験が無い方 (私のような) にとって、CI/CDパイプラインのイメージはなかなかつかみづらいものがあります。
今回はそういった方々に向けて、リポジトリに具体的なソースコードがない状態でGitLabのCI/CDパイプライン (DAG) を構成する方法をご紹介いたします。
本記事の対象の方
- GitLabで初めてCI/CDパイプラインを構成なさる方。
- ソースコードが無いけれど、GitLabでCI/CDパイプラインを構成してみたい方。
- キーワード
needsを使ってDAGを作ってみたい方。 - こちらのブログでRunnerを登録し、その次のアクションを探していらっしゃる方。
今回のブログのゴール
このブログのゴールはこちらです。
- ステージ と ジョブ の概要を理解する。
- needs を使ったジョブの依存関係の概要を理解する。
- 処理の内容が全部 echo と sleep だけのそれっぽいCI/CDパイプライン (DAG) を構成する。
このブログをお読みいただくにあたっての事前ご連絡事項
- 本記事は利用可能な Docker Runner が最低1つ、できれば2つ以上あるプロジェクトが既にあることが前提です。
- 本記事は GitLab Community Edition 14.6.1 における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
- 本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
- 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。
参考 (Docker Runnerについて) : Registering runners (deprecated) | GitLab
今回作成するCI/CDパイプラインの構成
このブログでは最終的に以下のパイプラインを作成します。
具体的なステージとジョブの構成は以下の通りです。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
| Build | build_a | ビルド処理A。 ジョブ build_common が完了後に実行可能。 ジョブ build_b との依存関係は無い。 | ruby:2.7-alpine | 10秒 |
| build_b | ビルド処理B。 ジョブ build_common が完了後に実行可能。 ジョブ build_a との依存関係は無い。 | ruby:2.7-alpine | 30秒 | |
| Test | test_common | ビルド済AとBに共通するテスト。 ジョブ build_a と build_b の両方が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 |
| unit_test_a | ビルド済Aのユニットテスト。 ジョブ build_a が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 | |
| unit_test_b | ビルド済Bのユニットテスト。 ジョブ build_b が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 20秒 | |
| Deploy | deploy_staging | ステージング環境へのデプロイ処理。 全てのテストが正常終了した後に実行可能。 | ruby:2.7-alpine | 10秒 |
各ジョブに想定する内容を記載していますが、今回はこれらの処理は実施せず、処理は全て echo で任意文字列を出力し、処理時間分の sleep を仕込むのみとします。
(筆者はアプリケーションの開発経験が無いため、上記のパイプラインの内容は想像によるものです。現実の開発とはかけ離れた内容となっているかもしれませんが、何卒ご容赦願います。)
最低限の用語説明
パイプラインを作成する前に、GitLabのCI/CDパイプラインにおける最低限の用語説明を記載します。
参考: CI/CD pipelines | GitLab
ジョブとは、何をすべきかを定義した単位です。
今回の例の場合、[build_common]、[build_a]、[unit_test_a] 等が該当します。
ステージとは、いつ実行するかを定義した単位で、1つ以上のジョブで構成されます。
今回の例の場合、[Build]、[Test] 等が該当します。
ランナーとは、ジョブを実行するアプリケーションです。
ランナーが複数存在する場合、並列実行可能なジョブを自動で並列実行します。
CI/CDパイプラインの作成
Step1: Docker Runnerの確認
最初に、今回CI/CDパイプラインを作成するプロジェクトに Docker Runner があることを確認してください。
CI/CDパイプラインを作成するプロジェクトに対し Owner もしくは Maintainer の権限を有するユーザーでサインインし、プロジェクトのページから [設定]>[CI/CD] を開きます。
[Runner] セクションを展開し、利用可能なRunnerが1つ以上 (出来れば2つ以上) あることを確認してください。
次に、Runnerの編集ボタン (鉛筆マーク) をクリックして、[この Runner は保護ブランチ上で起動されたパイプラインでのみ実行できます。] のチェックが外れていることを確認します。
チェックが付いている場合は、チェックを外して変更を保存してください。
なお、この画面からは現在利用できる Runner を確認できますが、それが Docker Runner か否かは確認できません。
この画面で Docker Runner の有無が確認できなかった場合は、Runnerの /etc/gitlab-runner/config.toml の executor 設定が docker になっていることを確認してください。
確認出来たらサインアウトします。
Step2: .gitlab-ci.yml を作る
GitLabのCI/CDパイプラインは .gitlab-ci.yml というファイルに構成を記載することで作成することができます。
デフォルトの設定では、このファイルはリポジトリのルートに配置する必要があります。
早速このファイルを作成します。
作業対象プロジェクトに対し Developer 以上の権限を有するユーザーでサインインし、プロジェクトのページで [Web IDE] をクリックします。
新規ファイルボタンをクリックします。
[.gitlab-ci.yml] をクリックします。
.gitlab-ci.yml が作成されたことを確認し、[コミット] をクリックします。
[新しいブランチを作成] を選択し、[新しいマージリクエストを開始する] にチェックを入れます。
コミットメッセージと新しいブランチ名は任意に指定してください。
最後に [コミット] をクリックします。
新規マージリクエストの画面に自動遷移します。
[説明] に任意の文字列を入力し、他はデフォルトのまま [作成 マージリクエスト] をクリックします。
マージリクエストの画面に遷移します。
先ほど作成したブランチ名のリンクをクリックします。
.gitlab-ci.yml がルートに作成されていることを確認します。
以上で .gitlab-ci.yml の作成は完了です。
Step3: 1ステージ、1ジョブを作成する
前のステップで作成した .gitlab-ci.yml に、1個のステージと1個のジョブを作成してみましょう。
プロジェクトのページで [CI/CD]>[Editor] をクリックし、左上の選択ボックスで先ほど作成したブランチを選択します。
.gitlab-ci.yml のエディタ画面になります。
この画面でCI/CDパイプラインの構成をポチポチ記載していきます。
この章では例として、下の表の黄色い部分を作成していきます。
ただし、ジョブの依存関係 (灰色の文字の部分) については後のステップで指定するので、今はいったん無視してください。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
| Build | build_a | ビルド処理A。 ジョブ build_common が完了後に実行可能。 ジョブ build_b との依存関係は無い。 | ruby:2.7-alpine | 10秒 |
| build_b | ビルド処理B。 ジョブ build_common が完了後に実行可能。 ジョブ build_a との依存関係は無い。 | ruby:2.7-alpine | 30秒 | |
| Test | test_common | ビルド済AとBに共通するテスト。 ジョブ build_a と build_b の両方が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 |
| unit_test_a | ビルド済Aのユニットテスト。 ジョブ build_a が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 | |
| unit_test_b | ビルド済Bのユニットテスト。 ジョブ build_b が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 20秒 | |
| Deploy | deploy_staging | ステージング環境へのデプロイ処理。 全てのテストが正常終了した後に実行可能。 | ruby:2.7-alpine | 10秒 |
まずはステージ Build_common を宣言します。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
stages: - Build_common
作成したステージ Build_common に、ジョブ build_common を作成します。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
stages: - Build_common build_common: stage: Build_common
ジョブ build_common の script に想定する処理内容を連想させる任意の echo コマンドを記載します。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
stages: - Build_common build_common: stage: Build_common script: - echo ビルドする前の共通処理。
ジョブ build_common の image にイメージを指定します。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
stages: - Build_common build_common: stage: Build_common image: ruby:2.7-alpine script: - echo ビルドする前の共通処理。
最後に、より本物のCI/CDパイプラインっぽく見せるための sleep を script に追加します。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
stages: - Build_common build_common: stage: Build_common image: ruby:2.7-alpine script: - echo ビルドする前の共通処理。 - sleep 10
これで1ステージ、1ジョブ分の yml が書けました！！
画面上部に [This GitLab CI configuration is valid.] と表示されていることを確認します。
ymlファイルに問題がある場合はアテンションマークとメッセージが表示されるので、内容を確認してください。
画面下部でコミットメッセージを任意に指定し、[Commit changes] をクリックします。
コミットすると自動でパイプラインが動き始めます。
[View pipeline] をクリックします。
パイプラインが成功したことを確認します。
先ほど作成したステージとジョブがどのように表示されているのかを確認します。
ジョブ名をクリックすると出力を確認することができますので、試しにクリックしてみましょう。
今回の場合はジョブの script で指定した echo の内容が出力に表示されていて、sleep も実行されていることが確認できます。
以上で 1ステージ、1ジョブの作成は完了です。
Step4: 全てのステージ、ジョブを作成する
前の手順を参考に残りのすべてのステージとジョブ (黄色い箇所) を作成してみましょう。
なお、各ジョブの依存関係 (灰色の文字の箇所) については後のステップで指定するので、今は気にしなくて大丈夫です。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
| Build | build_a | ビルド処理A。 ジョブ build_common が完了後に実行可能。 ジョブ build_b との依存関係は無い。 | ruby:2.7-alpine | 10秒 |
| build_b | ビルド処理B。 ジョブ build_common が完了後に実行可能。 ジョブ build_a との依存関係は無い。 | ruby:2.7-alpine | 30秒 | |
| Test | test_common | ビルド済AとBに共通するテスト。 ジョブ build_a と build_b の両方が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 |
| unit_test_a | ビルド済Aのユニットテスト。 ジョブ build_a が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 | |
| unit_test_b | ビルド済Bのユニットテスト。 ジョブ build_b が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 20秒 | |
| Deploy | deploy_staging | ステージング環境へのデプロイ処理。 全てのテストが正常終了した後に実行可能。 | ruby:2.7-alpine | 10秒 |
作ったのがこちらです！！(料理番組みたいになってる・・・)
stages: - Build_common - Build - Test - Deploy build_common: stage: Build_common image: ruby:2.7-alpine script: - echo ビルドする前の共通処理。 - sleep 10 build_a: stage: Build image: ruby:2.7-alpine script: - echo ビルド処理A。 - sleep 10 build_b: stage: Build image: ruby:2.7-alpine script: - echo ビルド処理B。 - sleep 30 test_common: stage: Test image: ubuntu:18.04 script: - echo ビルド済AとBに共通するテスト。 - sleep 10 unit_test_a: stage: Test image: ubuntu:18.04 script: - echo ビルド済Aのユニットテスト。 - sleep 10 unit_test_b: stage: Test image: ubuntu:18.04 script: - echo ビルド済Bのユニットテスト。 - sleep 20 deploy_staging: stage: Deploy image: ruby:2.7-alpine script: - echo ステージング環境へのデプロイ処理。 - sleep 10
こちらをコミットすると、このようなパイプラインができます。
この章でやるべきことは以上なのですが、この時点のパイプラインの実行順序について少し補足説明します。
【補足】依存関係や実行条件を指定していない場合のステージとジョブの実行順序
この時点で作成できたパイプラインを例に、ステージとジョブの実行順序について説明致します。
ステージの実行順序につきまして。
ステージは .gitlab-ci.yml で宣言した stages の順番で実行されます。
今回の場合stages の宣言は以下の通りでしたので、[Build_common]->[Build]->[Test]->[Deploy] の順になります。
stages: - Build_common - Build - Test - Deploy
stages を仮に以下の通りに宣言した場合は、[Build]->[Deploy]->[Test]->[Build_common] の順になります。
stages: - Build - Deploy - Test - Build_common
また、パイプラインは後続の step6 で設定する needs 等の依存関係や実行条件を指定しない場合、「前のステージのジョブが全て正常終了したときのみ、次のステージが実行される」という特性があります。
よって、この時点のパイプラインで仮にステージ [Build] のジョブが失敗した場合、後続のステージ [Test] と [Deploy] は実行されません。
stages: - Build_common - Build - Test - Deploy
次に、ステージ内のジョブの実行順序につきまして。
この時点のパイプラインは依存関係や実行条件などを指定していないため、そのステージの処理が開始し次第ジョブは並列に実行されます。
また、並列実行数は利用できるRunnerに依存します。
例えば、利用可能なRunnerが2個だった場合。
この時点のパイプラインにおけるステージ [Test] には3つジョブがありますが、Runnerが2個なので同時実行できるジョブは2つです。
したがって以下の画面のように、2つだけ並列実行され、1つはRunner待ち状態になります。
利用可能なRunnerが3個だった場合。
この場合は並列実行できるジョブは3つになります。
したがって、ジョブが3つあるステージ [Test] でも3つ全部のジョブを並列実行できます。
この時点のパイプラインに関する補足は以上です。
後のステップで、依存関係を作って "それっぽい" CI/CDパイプラインを作っています。
Step5: デフォルトの image を指定し、各ジョブでの image 指定を省略する
依存関係を作る前に・・・。
現状、各ジョブでイメージを image で指定しています。
ですが今回のジョブの半分以上は ruby:2.7-alpine を使っています。
グローバルキーワード default でまとめて宣言し、同じ設定をしている行を省略させます。
参考: `.gitlab-ci.yml` keyword reference | GitLab
Step.3 や Step.4 と同様にパイプラインエディターを開き、一番上 (stagesより上)に以下を追記します。
default: image: ruby:2.7-alpine
続いて、各ジョブの中で image: ruby:2.7-alpine と設定している行を全て削除します。
(Test系のジョブは異なるイメージを利用しているので、それらについては image の設定は削除しないでください。)
build_common: stage: Build_common image: ruby:2.7-alpine <- 消す行 script: - echo ビルドする前の共通処理。 - sleep 10
最終的に以下の通りになったことを確認し、コミットしましょう。
default: image: ruby:2.7-alpine stages: - Build_common - Build - Test - Deploy build_common: stage: Build_common script: - echo ビルドする前の共通処理。 - sleep 10 build_a: stage: Build script: - echo ビルド処理A。 - sleep 10 build_b: stage: Build script: - echo ビルド処理B。 - sleep 30 test_common: stage: Test image: ubuntu:18.04 script: - echo ビルド済AとBに共通するテスト。 - sleep 10 unit_test_a: stage: Test image: ubuntu:18.04 script: - echo ビルド済Aのユニットテスト。 - sleep 10 unit_test_b: stage: Test image: ubuntu:18.04 script: - echo ビルド済Bのユニットテスト。 - sleep 20 deploy_staging: stage: Deploy script: - echo ステージング環境へのデプロイ処理。 - sleep 10
コミット後、image: ruby:2.7-alpine の行を消したジョブ ([build_common] 等) の出力を確認します。
ジョブ内でイメージを明示的に指定していませんが、グローバルキーワード Default で指定したイメージが使われていることが確認できます。
デフォルトの image を指定し、各ジョブでの image 指定を省略する作業は以上です。
(この作業ではパイプラインの構成自体は変更がないので、前のステップと見た目は変わっていません。)
Step6: 表からジョブの依存関係を読み取り、needsで指定する
ようやく本題のジョブ依存関係を作ります。
まず、以下の表の黄色いセルの赤字部分が依存関係に必要な情報になります。
| ステージ | ジョブ | 想定する処理内容 | イメージ | 処理時間 |
|---|---|---|---|---|
| Build_common | build_common | ビルドする前の共通処理。 一番最初に実行する。 | ruby:2.7-alpine | 10秒 |
| Build | build_a | ビルド処理A。 ジョブ build_common が完了後に実行可能。 ジョブ build_b との依存関係は無い。 | ruby:2.7-alpine | 10秒 |
| build_b | ビルド処理B。 ジョブ build_common が完了後に実行可能。 ジョブ build_a との依存関係は無い。 | ruby:2.7-alpine | 30秒 | |
| Test | test_common | ビルド済AとBに共通するテスト。 ジョブ build_a と build_b の両方が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 |
| unit_test_a | ビルド済Aのユニットテスト。 ジョブ build_a が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 10秒 | |
| unit_test_b | ビルド済Bのユニットテスト。 ジョブ build_b が完了後に実行可能。 他のテストジョブとの依存関係は無い。 | ubuntu:18.04 | 20秒 | |
| Deploy | deploy_staging | ステージング環境へのデプロイ処理。 全てのテストが正常終了した後に実行可能。 | ruby:2.7-alpine | 10秒 |
文字だとわかりずらいのですが、図にすると以下のような依存関係になります。
まず、ステージ [Build] のジョブ [build_a] の依存を設定します。
このジョブは ステージ [Build_common] のジョブ [build_common] が完了し次第実行可能です。
この場合、ジョブ [build_a] にキーワード needs を設定することで依存関係を指定できます。
needs は様々な使い方ができますが、今回は needs: ["前提となるジョブ名"] で指定します。
ジョブ [build_a] に以下のように needs を指定してみましょう。
参考: `.gitlab-ci.yml` keyword reference | GitLab
build_a: stage: Build needs: ["build_common"] script: - echo ビルド処理A。 - sleep 10
上記のようにジョブ [build_a] に needs の設定ができたら、コミットします。
パイプラインの画面に遷移したら、"Group jobs by" の [Job dependencies] をクリックし、"Show dependencies" を有効にします。
すると何やら依存関係っぽい線が引かれた図が表示されます！集中線入れるほどのことかいな。
この調子で実行に際し前提となるジョブがあるジョブに対し、キーワード needs を設定していきます。
前提となるジョブが複数ある場合は、needs: ["前提となるジョブ名A", "前提となるジョブ名B",・・・] と指定します。
最終的に .gitlab-ci.yml は以下の通りになります。
default: image: ruby:2.7-alpine stages: - Build_common - Build - Test - Deploy build_common: stage: Build_common script: - echo ビルドする前の共通処理。 - sleep 10 build_a: stage: Build needs: ["build_common"] script: - echo ビルド処理A。 - sleep 10 build_b: stage: Build needs: ["build_common"] script: - echo ビルド処理B。 - sleep 30 test_common: stage: Test needs: ["build_a", "build_b"] image: ubuntu:18.04 script: - echo ビルド済AとBに共通するテスト。 - sleep 10 unit_test_a: stage: Test needs: ["build_a"] image: ubuntu:18.04 script: - echo ビルド済Aのユニットテスト。 - sleep 10 unit_test_b: stage: Test needs: ["build_b"] image: ubuntu:18.04 script: - echo ビルド済Bのユニットテスト。 - sleep 20 deploy_staging: stage: Deploy needs: ["unit_test_a", "unit_test_b", "test_common"] script: - echo ステージング環境へのデプロイ処理。 - sleep 10
上の変更をコミットします。
CI/CDパイプライン画面に遷移したら"Group jobs by" の [Job dependencies] をクリックし、"Show dependencies" を有効にします。
するとなんと、中身の処理は echo と sleep だけのくせに、こんな立派な見た目のCI/CDパイプラインができます！
また、Runnerが2個以上ある場合、タイミングがいいと以下の図のように、ジョブ [unit_test_a] が前のステージ [Build] の ジョブ [build_b] の完了を待たずに開始されていることも確認できます。
同じ画面で [Needs] タブを開くと、有効非巡回グラフ (Directed Acyclic Graph, DAG) を確認することができます。
むむむ・・・処理内容が echo と sleep だけのくせに、やたらにそれっぽい図が表示されています。
参考: Directed Acyclic Graph | GitLab
これで今回作成する予定だった、echo と sleep だけの処理しか含まないCI/CDパイプラインが完成しました。
この後少しだけ、キーワード needs を指定する前と後で何が変わったかについて補足します。
【補足】基本的なパイプラインとDAGパイプラインの違い
GitLab DocsにあるCI/CDパイプラインの種類の定義に基づくと、実は step5 までのパイプラインは ”Basic pipelines (基本的なパイプライン)" で、step6 でキーワード needs で依存関係を指定したパイプラインは "Directed Acyclic Graph (DAG) pipelines (有効非巡回グラフパイプライン)" に分類されます。
参考: CI/CD pipelines | GitLab
step6 で依存関係を指定したことによりグラフィカルな変化が出ることまでは確認しましたが、DAGパイプラインの真価は処理時間の高速化にあります。
今回の場合、この高速化の効果を視覚的に確認できるのが、ジョブ [unit_test_a] が実行されるタイミングです。
以下は step5 までで使用していた Basic pipeline の場合です。
この場合、ジョブ [unit_test_a] は前提ジョブ [build_a] が完了しているにもかかわらず、前ステージ [Build] が完了するまで待たなければなりません。
一方、step6 で作成した DAG pipelines の場合。
キーワード needs で依存関係を指定したことにより、ジョブ [unit_test_a] は前提ジョブ [build_a] が完了したら前ステージ [Build] の完了を待たずに実行されます。
この様にDAGパイプラインは前ステージの完了を待たずに、依存関係を満たしたジョブを実行できます。
今回のパイプラインのジョブの場合において、Basic pipeline と DAG pipeline の処理時間の違いを Docker Runner の数を考慮して以下に示します。
(ここでいう処理時間とは、各ジョブで指定した sleepの秒数 = そのジョブの処理時間と仮定し、パイプライン全体が終了するまでの時間を指します。パイプラインが終了するまでにかかる時間の実測値ではございません。また、イメージの pull にかかる時間などはここでは考慮していません。)
Docker Runnerの数が2個の時、Basic pipeline と DAG pipeline で処理時間に差があります。
これが、DAGパイプラインを使用することで前のステージの完了を待たずにジョブを進めたことによる効果です。
Docker Runnerの数を3個にすれば Basic pipeline でも同様の処理時間になりますが、できるだけ Runner を効率よく使用するという点を考慮すると、今回のパイプラインにおいては Docker Runner 2個で DAGパイプラインを構成するのが最も適正であると言えます。
なお、DAGパイプラインにおいて Docker Runner が2個の時と3個の時で処理時間は変わらないことについて。
詳細は省きますが、今回のパイプラインで仮にRunnerが無限個あると仮定したとき、最大並列実行ジョブ数は Basic pipeline だと理論上 3 、DAG pipeline だと理論上 2 です。
つまり今回のパイプラインにおいて、Basic pipelineの場合は Docker Runner を4個以上にしても処理時間は70秒より速くなりません。また、DAG pipeline の場合は Docker Runner を3個以上にしても処理時間は70秒より速くなりません。
このため、前述の表で DAG pipeline において Docker Runner が2個の時と3個の時で処理時間は変わらないという結果になります。
最後に
この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。
- ステージ と ジョブ の概要を理解する。
- needs を使ったジョブの依存関係の概要を理解する。
- 処理の内容が全部 echo と sleep だけのそれっぽいCI/CDパイプライン (DAG) を構成する。
GitLabではリポジトリのルートに .gitlab-ci.yml さえあれば、具体的なソースコードが無くてもCI/CDパイプライン (DAGパイプライン) っぽいものは作成可能です。
ソースコードが無い状態でもCI/CDパイプライン (DAGパイプライン) をお試しになりたい場合などで、今回の記事が参考になれば幸いです。
GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品 お問い合わせ
今までのGitLabの検証ブログはこちらです。
GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。