この記事では、アプリケーション設計で一般的なコンポーネントとその役割について説明します。
紹介#
GitLab 8.0 以降、GitLab CI は GitLab に統合されています。プロジェクトに .gitlab-ci.yml ファイルを追加し、Runner を追加するだけで、継続的インテグレーションを行うことができます。さらに、GitLab のアップグレードに伴い、GitLab CI はますます強力になりました。この記事では、GitLab CI を使用して継続的インテグレーションを行う方法について説明します。
いくつかの概念#
GitLab CI を紹介する前に、関連する継続的インテグレーションの概念を見てみましょう。
パイプライン#
パイプラインは、ビルドタスクの 1 回分であり、依存関係のインストール、テスト実行、コンパイル、テストサーバーへのデプロイ、本番サーバーへのデプロイなど、複数のプロセスを含むことができます。コミットまたはマージリクエストのマージは、パイプラインをトリガーすることができます。以下の図に示すように。
+------------------+ +----------------+
| | トリガー | |
| コミット / MR +---------->+ パイプライン |
| | | |
+------------------+ +----------------+
ステージ#
ステージはビルドの段階を表します。つまり、前述のプロセスです。1 つのパイプライン内で複数のステージを定義できます。これらのステージには次の特徴があります。
すべてのステージは順番に実行されます。つまり、1 つのステージが完了すると、次のステージが開始されます。
すべてのステージが完了すると、ビルドタスク（パイプライン）が成功します。
ステージのいずれかが失敗すると、その後のステージは実行されず、ビルドタスク（パイプライン）は失敗します。
したがって、ステージとパイプラインの関係は次のとおりです。
+--------------------------------------------------------+
| |
| パイプライン |
| |
| +-----------+ +------------+ +------------+ |
| | ステージ1 |---->| ステージ2 |----->| ステージ3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
ジョブ#
ジョブはビルドの作業を表し、特定のステージで実行される作業を示します。ステージ内で複数のジョブを定義できます。これらのジョブには次の特徴があります。
同じステージ内のジョブは並行して実行されます。
同じステージ内のすべてのジョブが成功した場合、そのステージは成功します。
ジョブのいずれかが失敗すると、そのステージは失敗し、ビルドタスク（パイプライン）は失敗します。
したがって、ジョブとステージの関係図は次のとおりです。
+------------------------------------------+
| |
| ステージ1 |
| |
| +---------+ +---------+ +---------+ |
| | ジョブ1 | | ジョブ2 | | ジョブ3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
紹介#
Runner を設定したら、プロジェクトのルートディレクトリに .gitlab-ci.yml ファイルを追加する必要があります。 .gitlab-ci.yml ファイルを追加すると、コードのコミットや MR のマージごとに自動的にビルドタスクが実行されます。
パイプラインはどのようにトリガーされるか覚えていますか？パイプラインもコードのコミットや MR のマージによってトリガーされます！では、パイプラインと .gitlab-ci.yml の関係は何でしょうか？実際、.gitlab-ci.yml はパイプラインを定義するだけです！
基本的な書き方#
.gitlab-ci.yml の書き方を見てみましょう。
# ステージを定義
stages:
- build
- test
# ジョブを定義
job1:
stage: test
script:
- echo "I am job1"
- echo "I am in test stage"
# ジョブを定義
job2:
stage: build
script:
- echo "I am job2"
- echo "I am in build stage"
簡単ですね！stages キーワードを使用して、パイプラインの各ビルド段階を定義し、いくつかの非キーワードを使用してジョブを定義します。各ジョブでは、stage キーワードを使用して、そのジョブがどのステージに対応するかを指定します。ジョブ内の script キーワードは、最も重要な部分であり、各ジョブが実行するコマンドを表します。
以前に説明したステージとジョブの関係を思い出し、上記の例の実行結果を予想してみましょう。
I am job2
I am in build stage
I am job1
I am in test stage
はい、stages で定義したように、build ステージは test ステージよりも前に実行されるため、stage:build のジョブが最初に実行され、その後 stage:test のジョブが実行されます。
よく使われるキーワード#
以下はよく使われるキーワードのいくつかです。詳細な内容については、公式ドキュメントを参照してください。
stages
ステージを定義します。デフォルトでは、build、test、deploy の 3 つのステージがあります。
types
stages の別名です。
before_script
すべてのジョブの実行前に実行されるコマンドを定義します。
after_script
GitLab 8.7+ および GitLab Runner 1.2+ が必要です。
すべてのジョブの実行後に実行されるコマンドを定義します。
variables && Job.variables
GitLab Runner 0.5.0+ が必要です。
環境変数を定義します。ジョブレベルの環境変数が定義されている場合、そのジョブはジョブレベルの環境変数を優先して使用します。
cache && Job.cache
GitLab Runner 0.7.0+ が必要です。
キャッシュする必要のあるファイルを定義します。各ジョブの開始時に、Runner は.gitignore ファイル内のファイルを削除します。一部のファイル（例：node_modules/）を複数のジョブで共有する必要がある場合、各ジョブで npm install を実行するしかありません。これは非常に不便ですので、これらのファイルをキャッシュする必要があります。キャッシュされたファイルは、ジョブ間だけでなく、パイプライン間でも使用できます。
具体的な使用方法については、公式ドキュメントを参照してください。
Job.script
ジョブが実行するコマンドを定義します。必須項目です。
Job.stage
ジョブのステージを定義します。デフォルトは test です。
Job.artifacts
ジョブで生成されたアーティファクトを定義します。ジョブが成功した後、生成されたファイルはアーティファクト（バイナリファイルなど）として保持され、GitLab にパッケージ化され、その後、GitLab のプロジェクトページからそのアーティファクトをダウンロードできます。注意：artifacts と cache を混同しないでください。