Zenn
🐡

初心者でもわかるCI/CDとは？｜目的・仕組み・始め方

に公開
初心者向け
CI/CD
tech

はじめに

ソフトウェア開発の現場でよく耳にする「CI/CD（シーアイ・シーディー）」

私は今の現場にきて初めてCICDの仕組みに触れましたが、多くの開発者がCICDによるテストは経験しているものです。
しかし、経験していてもCICDはどのような仕組みで動いているかに関しては、曖昧な状態ではないでしょうか。

実は、CI/CDは開発効率の向上や品質の安定化に大きく貢献してくれる仕組みであり、初心者でも理解しやすい考え方がベースになっています。

この記事では、CI/CDとは何か、その目的や手法、メリット・導入方法について、やさしく解説していきます。

CI/CDとは？

CI/CDは、以下の2つのプロセスを組み合わせた略称です。

  • CI（Continuous Integration／継続的インテグレーション）
  • CD（Continuous Delivery／継続的デリバリー、またはContinuous Deployment／継続的デプロイ）

CI/CDを導入することで、コードの変更を自動的にテスト・ビルド・デプロイし、素早く高品質なソフトウェアをリリースすることが可能になります。

CI（継続的インテグレーション）とは？

CIは、複数の開発者が同じリポジトリに頻繁にコードを統合（＝マージ）するためのプロセスです。

具体的な手順

  1. 開発者がコードをGitなどのバージョン管理システムにプッシュする。
  2. 自動でテストスクリプトや静的解析ツールが走る。
  3. テストにパスすればマージ可能、失敗すれば修正を促す。

CIの目的

  • バグの早期発見
  • テストの自動化による品質向上
  • コード統合のトラブル防止

CD（継続的デリバリー／継続的デプロイ）とは？

CDには2つの意味があります：

用語 内容
Continuous Delivery（継続的デリバリー） テストに通ったコードを本番環境にリリース可能な状態まで準備すること。手動でリリースボタンを押す。
Continuous Deployment（継続的デプロイ） テストに通ったコードを自動で本番環境にデプロイすること。
極端な運用であれば人の介入は不要であるが、
多くの運用では手動で承認のステップを挟むことが多い（Slack / GitHub Actions / Jenkins などで「デプロイボタンを押す」運用）

CDの目的

  • リリース頻度の向上（数日に1回 → 数時間に1回も可能）
  • 手動作業によるミスの防止
  • 常に安定した状態でリリース可能にする

なぜCI/CDが必要なのか？

  • チーム開発でのコードの衝突を防ぎたい
  • テストを忘れたり、面倒だったりして品質が下がってしまう
  • 本番反映が不安で、リリース作業に時間がかかる

CI/CDはこうした課題を自動化とルール化によって解決します。
結果として、開発チーム全体のスピード・品質・信頼性が向上します。

CI/CDで使われる主なツール

分類 ツール例 特徴
CI/CD一体型 GitHub Actions, GitLab CI/CD, CircleCI Gitと連携しやすく、無料枠も充実
専用ツール Jenkins 柔軟性が高いが初期構築が必要
補助ツール Docker, Kubernetes コンテナやデプロイの環境を整える

CI/CDを始めるには？

1. リポジトリを準備（GitLabなど）

プロジェクトのコードを管理するためにGitを使います。CI/CD機能を使うにはGitLabリポジトリでプロジェクトを作成します。

2. GitLab CI/CDの設定ファイルを作成

GitLabでは.gitlab-ci.ymlというファイルをプロジェクトルートに置くことで、CI/CDを設定できます。

例：

stages:
  - test

test_job:
  stage: test
  image: alpine
  script:
    - echo "Running CI pipeline..."
    - echo "This pipeline is working correctly!"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  tags:
    - k8s

.gitlab-ci.yml 各オプションの意味まとめ

それぞれのオプションの意味は以下の通りです。

stage

CIジョブを複数のステージに分割して実行するための定義です。
ここでは test ステージでジョブが実行されることを示しています。

stages:
  - test

image

ジョブが実行される仮想環境【Dockerコンテナ】のベースイメージを指定します。

  • 試験的に echo などを実行するだけであれば、軽量な alpine イメージがおすすめです。
  • Node.js プロジェクトなどで npm や yarn を使用する場合は、node:18 などの公式イメージを指定します。
image: alpine

※ 必要に応じて適切なイメージに変更してください。

script

CIジョブで実行する具体的なコマンドを記述します。
この例では、.gitlab-ci.ymlのみでCI/CDが動作することを確認するために echo を使っています。

script:
 - echo "Running CI pipeline..."
 - echo "This pipeline is working correctly!"

※ 「CI/CDが正常に実行されているか」は、ログに出力される内容で目視確認をすることができます。

rules

ジョブが実行される条件・トリガーを指定します。
ここでは、mainブランチに変更があったときのみジョブを実行します。

rules:
  - if: '$CI_COMMIT_BRANCH == "main"'

tags

CIジョブを実行する対象のRunnerを指定します。

tags:
    - k8s

  • tags を指定しない場合は、GitLab.comの Shared Runner (共有ランナー) が自動的に使用されます。

  • Shared Runner は設定不要で手軽ですが、以下のようなデメリットもあります：

    • 他ユーザーと共有のため、待ち時間の発生
    • セキュリティ面の制約
    • 無料枠（月2000分）　の制限

そのため、企業やチームで本格的にCI/CDを行う場合は、自前の専用Runnerを構築することが望ましいです。

※ tags: で指定するタグ名は、Runner登録時に自由に設定可能です。

このようにさまざまな条件や実施内容を指定することができます。
ここで挙げたのは代表的なオプションであり、このほかにもさまざまなオプションを指定することが可能です。

3. 自動実行されることを確認する

テストやビルドがコミット・マージリクエストごとに実行されるようになります。

おわりに：CI/CDで「安心して変更できる」開発を

CI/CDを導入することで、「ミスを恐れずに変更できる」環境が整います。
結果として、ユーザーに価値ある機能をより早く届けられるようになります。

最初は簡単なCIからでもOKです。ぜひ、自分のプロジェクトにも取り入れてみてください！

Discussion