このチュートリアルの目的は、GitLabのすべてのドキュメントを読まなくても30分で開始できるようにするGitLab CI / CDの概要を説明することです。このチュートリアルは、GitLab CI / CDなどのCI / CDツールをいじくり回したい初心者を対象としています。このチュートリアルでは、CI / CDとは何か、GitLabのツールを使用することにした理由、および.gitlab-ci.yamlサンプルアプリケーションを使用してを作成する方法のウォークスルーについて簡単に説明します。

CI / CD

CI / CDは、継続的インテグレーション/継続的デリバリー/継続的デプロイの略です。これにより、チームはソフトウェアをより高速に構築、テスト、リリースできます。CI / CDは、可能な場合は手動による人間の操作を排除し、最終的な手動コードの本番環境へのデプロイを除くすべてを自動化します。このプラクティスを実装する際の課題の1つは、CI / CDパイプラインの構築に必要なさまざまなツールとシステムを統合することです。たとえば、コードをBitbucketに保存し、プライベートインフラストラクチャの自動テストスイートでテストして、アプリケーションをAWSまたはMicrosoftAzureにデプロイすることができます。複数のシステムに存在する複雑なアプリケーションは、すべての組織がシームレスなCI / CDパイプラインを実装しているわけではありません。

なぜGitLabCI / CDなのですか？

私がGitLabCI / CDを使用している理由は、3つあります。1つのツールで完全なCI / CDパイプラインソリューションを構築できること、高速であること、オープンソースであることです。同じ場所にGitLabCI / CDを使用すると、別のアプリケーションなしで、チケットの作成、リクエストのマージ、コードの記述、CI / CDツールのセットアップを行うことができます。それは本質的にワンストップショップです。GitLab CI / CDは、GitLabRunnersでビルドを実行します。ランナーは、GitLab CIAPIを介して事前定義されたステップを実行する分離された仮想マシンです。このツールだけで、単一のインスタンスで実行する場合と比較して、プロジェクトをパイプラインビルドで実行することができます。GitLab Runnersの詳細については、このリンクをご覧ください。最後に、これはオープンソースなので、いつでもコードベースに貢献し、問題が発生したときに新しい問題を作成できます。

シナリオ

データベース内の本のリストを取得するNode.jsAPIがあるとしましょう。コードをビルド、テスト、デプロイの3つのフェーズにプッシュするパイプラインを作成できます。パイプラインは、同様の特性によってグループ化されるステップ群です。これらのフェーズでは、パイプラインは次の3つのタイプで定義されます。

• プロジェクトパイプライン
• 継続的インテグレーションパイプライン
• パイプラインを展開する

3つのパイプラインが実行するステップは、ジョブと呼ばれます。これらの特性によって一連のジョブをグループ化する場合、それはステージと呼ばれます。ジョブはパイプラインの基本的な構成要素です。それらはステージでグループ化でき、ステージはパイプラインにグループ化できます。ジョブ、ステージ、パイプラインの階層の例を次に示します。

A.）ビルド
i。NPMの依存関係をインストールする
ii。ES-Linteriiiを実行します
。Code-Minifier
Bを実行します。）テスト
i。ユニット、機能、およびエンドツーエンドのテストを実行します。
ii。pkgを実行してNode.jsアプリケーションをコンパイルします
C.）デプロイ
i。本番
環境1.）AWSiiでEC2インスタンスを起動します
。ステージング
1.）ローカル開発サーバーで起動します

この階層では、3つのコンポーネントすべてが3つの異なるパイプラインと見なされます。主な箇条書き—ビルド、テスト、およびデプロイはステージであり、これらのセクションの下の各箇条書きはジョブです。これをGitLabCI / CDyamlファイルに分割してみましょう。

GitLab CI / CDの使用

GitLab CI / CDを使用するに.gitlab-ci.ymlは、プロジェクトのルートで呼び出されるファイルをGitLabリポジトリに作成し、以下を追加しますyaml。

image: node:10.5.0stages:
 — build
 — test
 — deploybefore_script:
 — npm install

GitLab CI / CDの使用

GitLab CI / CDを使用するに.gitlab-ci.ymlは、プロジェクトのルートで呼び出されるファイルをGitLabリポジトリに作成し、以下を追加しますyaml。

image: node:10.5.0stages:
 — build
 — test
 — deploybefore_script:
 — npm install

それでは、ビルド段階に特化した仕事から始めましょう。この仕事を呼びますbuild-min-code。このジョブでは、依存関係をインストールしてコードを縮小する必要があります。これは、scriptディレクティブを使用して開始できます。scriptディレクティブは、ランナーの中に実行されますシェルスクリプトです。次に、このジョブを「ビルド」ステージに割り当てます。ジョブをステージに割り当てるには、stageディレクティブを使用します。

build-min-code：
ステージ：ビルド
スクリプト：
— npm install
— npm run minifier

これで、ビルドステージに関連付けられたジョブがあり、テストステージでそれを実行します。テストジョブが呼び出さrun-unit-testれ、APIでnpmスクリプトを使用してテストを実行しますnpm test。

run-unit-test：
ステージ：テスト
スクリプト：
— npm run test

最後に、Deployステージを処理するジョブを追加します：deploy-production、deploy-staging。この例では、展開のために2つの異なるジョブ（ステージングと本番）があります。これらのジョブは、以前のジョブと同じレイアウトを反映しますが、わずかな変更があります。現在、すべてのジョブは、コードのプッシュまたはブランチでトリガーされるように自動的に設定されています。コードをステージングと本番環境にデプロイするときに、このようなことはしたくありません。これを防ぐために、onlyディレクティブを使用します。onlyディレクティブは、ジョブを実行するためにブランチやタグの名前を定義します。ジョブは次のようになります。

deploy-staging:
 stage: deploy
 script:
   — npm run deploy-stage
 only:
   — developdeploy-production:
 stage: deploy
 script:
   — npm run deploy-prod
 only:
   — master

このイメージdeploy-stagingから、コードプッシュがmasterブランチに対して行われたためを除いて、3つのステージとジョブすべてがトリガーされます。GitLab CI / CDには、実行中のジョブとステージ、およびビルド中に発生しているエラーを表示するのに役立つ直感的なインターフェイスが付属しています。以下は.gitlab-ci.yamlファイルの最終バージョンです。これを自分でテストしたい場合は、サンプルアプリケーションへのリンクを次に示します。

image: node:10.5.0stages:
  - build
  - test
  - deploybefore_script:
  - npm installbuild-min-code:
  stage: build
  script:
    - npm install
    - npm run minifierrun-unit-test:
  stage: test
  script:
    - npm run testdeploy-staging:
  stage: deploy
  script:
    - npm run deploy-stage
  only:
    - developdeploy-production:
  stage: deploy
  script:
    - npm run deploy-prod
  only:
    - master

上記の項目は、GitLab CI / CDが提供できる機能の概要です。GitLab CI / CDには、Dockerイメージを構築して公開し、サードパーティのツールと統合することで、コードベースの自動化をより詳細に制御する機能があります。このチュートリアルがお役に立てば幸いです。読んでくれてありがとう！