1.はじめに
1.1 概要
最近業務でGitLab SaaS版を用いてのCICD実装に関わることがありました。
GitLabが手軽に試せることを知ったため、自分の手でも試してみました。
今回は運用レベルではなく簡易的な形での実装を説明していきたいと思います。
1.2 CICDとは
ソフトウェア開発などをより効率良く進めるための手法・考え方で、
開発における、作業 → テスト → 公開の一連の流れを自動化する意味で使われることが多いです。
CIとは「継続的インテグレーション」の略です。
作成した資材などを統合(インテグレーション)し動作確認する流れを自動化することで
効率化し、より正確に開発を進めるができるようになります。
CDとは「継続的デリバリー」の略です。
動作確認などのテストが完了した成果物が自動的に提供(リリース、デプロイ)される仕組みのことで、リリースサイクルを大幅に短縮することができ継続的に自動更新できるようになります。
1.3 CI/CDパイプラインとは
CI/CDパイプラインとは、上述したCI/CDを実践するために必要な一連のステップを一つの流れにして自動化したものです。(以下パイプライン)
パイプラインを構築することで、コードや設定ファイルに変更があると
作業 → テスト → 公開までのステップが自動化されます。
1.4 GitLab SaaS版とは
GitLabは、単一のアプリケーションで開発サイクルの高速化を可能としたアプリケーション開発支援ツールです。
ソースコード管理やプロジェクトの進捗管理、上述したCI/CDパイプライン機能など開発に必要な機能がそろっています。
CI/CDパイプライン機能により、これまで手動作業で行っていたテストやデプロイなどの開発工程を自動化できるため、業務の効率化やリリーススピードの高速化が可能です。
GitLabにはSaaS版とSelf-Managed版がありますが今回は、SaaS版の無料プランであるFreeプランを用いています。
有料プランもありますが違いが気になった方は以下を参照下さい。
https://aslead.nri.co.jp/products/gitlab/column/gitlab-price-comparison.html
1.5 GitLabRunnerとは
GitLabでパイプライン処理を実行するために必要な実行環境がGitLabRunnerです。
Runnerには大きく分けて、Specific RunnerとShared Runnerの2種類あります。
前者は自前のサーバ(仮想・物理は問わない)にRunnerをインストールして、GitLabと連携することで実行する方法ですが、
後者はGitLabが共有してくれている環境で実行します。
今回は、Shared Runnerを用いて実施していきます。
2.使用したもの
・GitLab (SaaS版 Freeプラン)
3.実装方法
3.1 GitLabSaaSへのログイン方法
3.1.1 GitLabアカウントの登録
以下のURLに飛ぶと、GitLabのサインイン画面に飛びます。
https://gitlab.com/users/sign_in
今回は、一から作成する方法で実施していきます。
「まだアカウントをお持ちでない方はこちら。 今すぐ登録」
とあるので、「今すぐ登録」を押下します。
「または次でサインインします」から該当のアカウントを押下してサインインすることも可能
次の画面で、必要事項の入力を行い「登録する」を押下します。
すると、セキュリティ強化のため本人確認画面に遷移します。
「国または地域」で自分がいる国を選択したうえで、番号を入力します。
今回は、日本なので「Japan(+81)」を選択しています。
入力後は、「コードを送信」を押下して、認証コードが届くことを確認します。
コード入力後は「電話番号の確認」を押下します。
電話番号の確認が完了すると、そのままメールアドレスの確認に進みます。
自動的に認証メールが送信されるので、届いたメールを確認し認証コードを入力して「メールアドレスの確認」を押下しましょう。
無事確認ができたら次の画面で「Next」を押下します。
その後は、使用理由などを問われるので回答し「続行」を押下すると
無事登録が完了します。
この際、「次は何をしたいですか」の問いに対して
「新規プロジェクトを作成」にチェックを入れるとプロジェクトの作成画面に遷移します。
3.2 プロジェクトを作成
任意のグループ名とプロジェクト名を入力し、「プロジェクトを作成」を押下します。
グループ名は入力しなくとも自動で決めてくれますが
複数作るようになるとどれがどれだか分からなくなるので、
自分でつけておくのがお勧めです。
今回は
グループ名：Runner-test
プロジェクト名:test
とします。
3.3 パイプラインの実行方法
3.3.1 Runnerが使用可能か確認
プロジェクトの作成が完了すると、プロジェクトの画面に遷移します。
パイプラインを実行するために、まずGitLabRunnerが使用可能な状態かを確認します。
今回使用するのは、上述1.5の通りShared Runnerです。
画面左側にあるメニュー画面から、「設定」→「CI/CD」を押下します。
CI/CDの設定画面に遷移したら、「Runner」までスクロールし「展開」を押下します。
押下後、以下画像のようにRunnerの設定画面が展開されます。
共有Runner(Shared Runner)に注目し、
「このプロジェクトの共有Runnerを有効にする」にチェックマークが入ってれば問題ありません。
その下には、利用可能な共有Runner(Shared Runner)が表示されています。
使用する際には、タグと呼ばれる青字の文字列を後述のgitlab-ci.ymlに組み込みます。
3.3.2 パイプラインテストの実行
パイプラインが実行できる状態を確認できたので、
次にプロジェクトでパイプラインを実行する前のテストを実行します。
画面左側にあるメニュー一覧から、「ビルド」→「パイプライン」を押下します。
パイプライン画面に遷移すると、以下画像のように
「テストテンプレートを試す」とあるので押下します。
すると、テスト用のテンプレートが記載された「.gitlab-ci.yml」が表示されます。
この「.gitlab-ci.yml」がパイプライン実行の設定ファイルです。
YAML形式で実行したいコマンドなどを記述していきます。
全容は以下折りたたみの通りです。
テスト用テンプレート
# This file is a template, and might need editing before it works on your project.
# This is a sample GitLab CI/CD configuration file that should run without any modifications.
# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
# it uses echo commands to simulate the pipeline execution.
#
# A pipeline is composed of independent jobs that run scripts, grouped into stages.
# Stages run in sequential order, but jobs within stages run in parallel.
#
# For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages
#
# You can copy and paste this template into a new `.gitlab-ci.yml` file.
# You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword.
#
# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
environment: production
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
使用されている項目について軽く説明します。
stages:パイプライン実行におけるjobの実行順序を制御します。
○○-job:パイプライン上で実行したい処理の単位をjobといい、このjobを定義しています。パイプライン上で実行したいscriptや、諸条件をまとめています。定義する際は、必ずしも○○-jobという形にする必要はありません。
script:パイプライン上で実行したい処理内容です。
他にも記述時に使用する項目はありますが、今回は説明を省かせていただきます。
内容が確認できたら画面下にある「変更をコミットする」を押下します。
コミットメッセージは自動で入力されていますが変更しても問題ありません。
コミットを実行すると、自動的にパイプラインが流れます。
状態が「実行中」から「成功」になるまで待機します。
成功になると、指定したスクリプトが全て無事通ったことを意味します。
実行中
成功
結果だけでなく、実行ログの確認もする事が可能です。
「成功」状態になったパイプラインの「#10...」という数字部分を押下します。
画面遷移すると、記載したstagesとそのjobごとに分かれています。
ログを確認したいjob名を押下することで、jobごとの実行ログを確認することができます。
以下はbuild-jobのログです。
3.3.3 gitlab-ci.ymlの編集とパイプライン実行
テストにより実行できることが確認できたので、実際に自分でもgitlab-ci.ymlを編集してみます。
メニュー一覧より、プロジェクト名を押下します。
(今回の場合は、「test」)
今回は、テスト用テンプレートをそのまま上書きするのではなく
他のブランチを作成しその中で編集・動作確認を実施したいと思います。
プロジェクト画面に遷移後、「＋」→「新しいブランチ」の順に押下します。
新規ブランチ作成画面に遷移するので、任意のブランチ名を入力し
「ブランチを作成」を押下します。
作成元は「main」ブランチしかないためそのままとし、
ブランチ名は「test」とします。
ブランチを新しく作成すると、作成元の「main」ブランチを丸々コピーした状態になります。
ブランチが画像赤枠の通り「test」であることを確認し、「.gitlab-ci.yml」を押下します。
押下すると、上述3.3.2で実行したymlの中身が表示されます。
以下画像のように、画面右側に「編集」ボタンがあるので
「編集」→「単一のファイルを編集」を押下します。
編集画面に遷移するので、好きなように編集します。
今回は、実行環境にShared Runnerを利用するので
使用確認のために以下画像のようにしました。
tags:3.3.1の通り、使用可能なShared Runnerの下に表示される青字部分をタグと呼びます。使用したいShared Runnerのタグをこの部分に記載します。
stages:
- test-runner
shared-runner-test:
stage: test-runner
# Shared Runnerを明示的に指定する
tags:
- gitlab-org
script:
- cat /etc/*-release
- echo "Hello Gitlab CI/CD!"
編集後は画面の下方にある「変更をコミットする」を押下します。
押下すると、先ほど同様に自動的にパイプラインが実行されます。
マニュアルで実行する方法もありますがここでは割愛させていただきます。
無事実行されているか確認していきます。
メニュー一覧から、「ビルド」→「パイプライン」を押下します。
パイプライン実行画面に遷移すると、先ほど更新したパイプラインが
タグ：gitlab-orgのShared Runnerにて実行されたことが分かります。
実行ログは以下の通りです。
実装の流れは以上となります、お疲れ様でした！
4.最後に
CICDの実行方法は様々ありますが、今回はGitLabSaaSを用いる方法を紹介しました。
少しでもCICDというものに興味を持っていただければ幸いです。
業務でも一から実施したことがなく、用意された環境を使用するだけだったので新鮮でした。
今回は、特に気を付けていませんが
運用目線で考えると、ログイン方法や人が増えてきた際の権限付与など、
セキュリティ面も考慮する必要があると思うので、設定方法など調べていきたいと思います。
また、今回はShared Runnerという、GitLab社が公開しているRunnerを使用して実行しましたが
他にも、Spesific Runnerという自前のサーバなどを用いる方法もあるので
次回はそちらの実行方法もまとめていきたいと思います。
以上、最後まで読んでいただきありがとうございました。
5.参考文献
【図解】CI/CD とは？非エンジニアの方向けにわかりやすく解説します
GitLab（ギットラボ）の使い方を初心者向けに分かりやすく解説
GitLab CI/CD 基本編 ～チュートリアルで感覚を掴む～
GitLab CI/CD 発展編 ～GitLab Runnerの使い方～
GitLabでアカウント作成する手順GitLabでアカウント作成する手順
【GitLab】アカウントを作成（新規登録）する