この記事では、アプリケーション設計で一般的なコンポーネントとその役割について説明します。
概要#
GitLab 8.0 以降、GitLab CI は GitLab に統合されており、プロジェクトに.gitlab-ci.ymlファイルを追加し、ランナーを追加するだけで継続的なインテグレーションを行うことができます。さらに、GitLab のアップグレードに伴い、GitLab CI はますます強力になりました。この記事では、GitLab CI を使用して継続的なインテグレーションを行う方法について説明します。
いくつかの概念#
GitLab CI を紹介する前に、関連する継続的インテグレーションの概念を見てみましょう。
パイプライン#
パイプラインは、実際にはビルドタスクです。その中には、依存関係のインストール、テスト実行、コンパイル、テストサーバーへのデプロイ、本番サーバーへのデプロイなど、複数のフローが含まれることがあります。コミットやマージリクエストのマージなど、パイプラインはトリガーとして機能します。以下の図に示すように。
+------------------+ +----------------+
| | トリガー | |
| コミット / MR +---------->+ パイプライン |
| | | |
+------------------+ +----------------+
ステージ#
ステージはビルドの段階を表します。つまり、上記で言及したフローです。1 つのパイプライン内で複数のステージを定義することができます。これらのステージには次の特徴があります。
すべてのステージは順番に実行されます。つまり、1 つのステージが完了すると、次のステージが開始されます。
すべてのステージが完了すると、ビルドタスク（パイプライン）が成功します。
ステージのいずれかが失敗すると、後続のステージは実行されず、ビルドタスク（パイプライン）は失敗します。
したがって、ステージとパイプラインの関係は次のとおりです。
+--------------------------------------------------------+
| |
| パイプライン |
| |
| +-----------+ +------------+ +------------+ |
| | ステージ1 |---->| ステージ2 |----->| ステージ3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
ジョブ#
ジョブはビルドジョブを表し、ステージ内で実行される作業を表します。ステージ内で複数のジョブを定義することができます。これらのジョブには次の特徴があります。
同じステージ内のジョブは並行して実行されます。
同じステージ内のすべてのジョブが成功した場合、そのステージは成功します。
ジョブのいずれかが失敗すると、そのステージは失敗し、ビルドタスク（パイプライン）は失敗します。
したがって、ジョブとステージの関係図は次のとおりです。
+------------------------------------------+
| |
| ステージ1 |
| |
| +---------+ +---------+ +---------+ |
| | ジョブ1 | | ジョブ2 | | ジョブ3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
概要#
ランナーを設定したら、プロジェクトのルートディレクトリに.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 "私はジョブ1です"
- echo "私はテストステージにいます"
# ジョブを定義
job2:
stage: build
script:
- echo "私はジョブ2です"
- echo "私はビルドステージにいます"
簡単ですね！stagesキーワードを使用して、パイプラインの各ビルドステージを定義し、いくつかの非キーワードを使用してジョブを定義します。各ジョブでは、stageキーワードを使用してそのジョブがどのステージに対応するかを指定します。ジョブ内のscriptキーワードは非常に重要であり、各ジョブで実行するコマンドを表します。
以前に説明したステージとジョブの関係を思い出し、上記の例の実行結果を推測してみてください。
私はジョブ2です
私はビルドステージにいます
私はジョブ1です
私はテストステージにいます
はい、stagesで定義したように、ビルドステージはテストステージよりも前に実行されるため、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 を混同しないでください。