本文へスキップ
BecomeCoder
ブログ一覧Wikiコース一覧

CI/CDとは？GitHub Actionsの使い方を初心者向けにわかりやすく

#CI/CD#GitHub Actions#自動テスト#初心者

結論：CI/CDとは「コミットしたら、その先の作業を機械が自動でやる」しくみです。CIが自動テスト、CDが自動デプロイ。GitHub Actions なら、リポジトリの .github/workflows/ にYAMLを1枚置くだけで始まります。覚える言葉は workflow / job / step / uses の4つだけです。

Git の add → commit → push は覚えた。では、その push のあとに何が起きると嬉しいのか。この記事は「コミットしたあとを自動化する仕組み」だけに絞って説明します。Git の操作そのものは Gitの使い方入門、GitとGitHubの違いは GitとGitHubの違い にまとめてあります。

CI/CD とは何か

要するに、これまで人間が手で回していた「テストを走らせる → ビルドする → サーバーに上げる」を、機械が毎回まったく同じ手順で実行してくれる状態です。

push / プルリクエスト
        ↓
   CI：lint → test → build   ← 失敗したら赤信号。ここで止める
        ↓ 成功
   レビュー → マージ
        ↓
   CD：本番へ自動デプロイ

得られるものは3つです。早く気づける（壊れた変更をマージ前に検出）、手順が揃う（「私のPCでは動いた」がなくなる）、速く届く（小さな変更を何度でも安全に出せる）。考え方の全体像は CI/CD とは の回にまとまっています。用語の短い定義は CI/CD｜Wiki用語集、周辺の文化としては DevOps｜Wiki用語集 も参考に。

GitHub Actions の構造：覚える言葉は4つ

GitHub Actions は GitHub に標準で組み込まれた CI/CD の仕組みです。リポジトリに .github/workflows/ci.yml のようなYAMLファイルを置くと、それが「ワークフロー」として自動で動きます。

用語意味
workflow自動化のひとまとまり。YAMLファイル1つが1ワークフロー
jobワークフローの中の仕事。既定では並行に走る
stepjob の中の手順。上から順に1つずつ実行される
uses / runstep の中身。uses は公開部品を呼ぶ、run はシェルコマンドを実行する

最小のワークフローはこれだけです。

name: CI                     # 表示名

on: [push]                   # いつ動かすか（push されたら）

jobs:
  build:                     # job の名前（自由に付けられる）
    runs-on: ubuntu-latest   # どのOSの仮想マシンで動かすか
    steps:
      - uses: actions/checkout@<バージョン>   # リポジトリのコードを取り出す
      - run: echo "Hello, CI!"                # シェルコマンドを1つ実行

uses: で呼ぶのは、GitHub 上に公開されている再利用可能な部品です（@ の後ろにバージョンを固定して指定します）。「コードを取り出す」「言語の実行環境を用意する」といった定番の作業は、自分で書かずに部品を呼ぶだけで済みます。階層と用語の詳細は GitHub Actions の構造 を参照してください。

実務のワークフローを読む：lint → test → build

現場でよく見る形は、だいたい次の順です。

  1. checkout：リポジトリのコードを仮想マシンに取り出す。
  2. セットアップ：言語の実行環境を用意する。
  3. 依存の取得：ライブラリをインストールする。
  4. lint：書式・規約のチェック。
  5. build：ビルドが通るか。
  6. test：自動テストを走らせる。

読み方の勘所は2つです。step は上から順で、どれか1つでも失敗（終了コードが0以外）した時点で job は失敗して止まること。そして on: の書き方でトリガーが決まること。pull_request を入れておけば、プルリクエストが作られた時点でチェックが走るので、壊れた変更がマージされる前に止められます。行ごとの意味は ワークフロー YAML を読む（lint → test → build） で1行ずつ解説しています。

「CIが通っていないプルリクエストはマージしない」というルールにすると、main ブランチは常に「テストが通った状態」に保たれます。これが CI/CD の一番のねらいです。プルリクエストの流れ自体が曖昧なら GitHub とプルリクエスト と チーム開発フローの全体像 を先に読んでください。

デプロイまで自動化する（CD）と secrets

テストが通ったら公開です。ここで新しく出てくるのが次の3つです。

秘密情報の扱いは、初心者がいちばんやりがちな事故（トークンをそのままコミットして公開）に直結する部分です。実例つきの解説は デプロイまで（build → deploy） にあります。デプロイという言葉自体の整理は デプロイ｜Wiki用語集 を参照。

自動化には「自動で確かめられるもの」が要る

CIは魔法ではありません。CIがやってくれるのは、あなたが書いたチェックを毎回実行することだけです。テストコードが1本もないリポジトリでCIを組んでも、「ビルドが通った」以上のことは分かりません。

だから順序としては、まず自動テストを書けるようになってからCIを組むのが正解です。テストの書き方は 単体テストとは？テストコードの書き方 にまとめました。C#やJavaなら C# MVVMコース や Java MVVMコース で、赤→緑のリズムをブラウザ上で実行しながら覚えられます（無料・登録不要・環境構築なし）。

YAMLとコンテナに慣れておくと早い

CI/CD の設定ファイルはほぼすべてYAMLです。インデントで階層を表す形式なので、空白のズレがそのままエラーになるのが最初の壁になります。YAMLを手を動かして読み書きするなら、composeファイルとは ― 複数サービスを1枚で定義する がおすすめです。ブラウザ上のシミュレータでそのまま試せます。

もう1つ、CIの実行環境はたいていコンテナです。「どこでも同じ環境で動く」という発想を先に理解しておくと、runs-on や環境セットアップの意味がすんなり入ります。Dockerfileとは ― イメージの設計図 と Dockerコース をのぞいてみてください。設定をコードで管理する考え方は IaC｜Wiki用語集 にもつながります。

つまずきやすいところ

学ぶ順序（おすすめ）

  1. Gitの基本操作 をブラウザ上のシミュレータで手を動かして覚える。
  2. git push ― リモートへ送る でリモートとのやり取りを理解する。
  3. チーム開発フローの全体像 でブランチとプルリクエストの流れをつかむ。
  4. CI/CD とは → GitHub Actions の構造 → ワークフローYAMLを読む → デプロイまで と順に読む。
  5. Git のまとめ ― Git から CI/CD への道 で全体を復習する。

Become-Coder の Gitコース は全29回。前半のGit操作はブラウザ上のシミュレータで実際にコマンドを打って練習でき、CI/CDを扱う終盤は読み物として設定ファイルの読み方を学ぶ構成です。日本語・無料・インストール不要です。

次に読む

← ブログ一覧に戻る