12
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ham0215

[GitHub入門] GitHub Actions CI/CDで自動化

12
Last updated at Posted at 2025-12-16

前回（No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow）では、チーム開発の交通ルールであるブランチ戦略について解説しました。

第8回となる今回は、そのルールを守りつつ、日々の繰り返し作業を機械に任せる 「GitHub Actions（CI/CD）」 について解説します。
「テストの実行忘れ」や「複雑なデプロイ手順」といった悩みは、仕組みで解決できます。自動化を取り入れて、より快適な開発環境を作りましょう。

GitHub入門シリーズ 全10回本記事は「GitHub入門」全10回のNo.8です。

github-introduction.png

##今回のゴール

  1. CI/CDの基本概念（なぜ自動化するのか）を理解する
  2. GitHub Actionsで「テスト自動化」のワークフローを作成する
  3. マーケットプレイスを活用して簡単に設定を行う
  4. 自動化による工数削減と品質向上のメリットを知る

1. CI/CDとは？（人間がやるべき仕事、機械に任せる仕事）

CI/CD とは、ソフトウェアを安全かつ高速に届けるための自動化の仕組みです。

  • CI（Continuous Integration / 継続的インテグレーション）:
    • 役割: コードが提出されたら、自動でテストやLint（構文チェック）を行う
  • CD（Continuous Delivery / 継続的デリバリー）:
    • 役割: テストに通ったコードを、自動でサーバーへ反映（デプロイ）する

人間は「コードを書く」ことに集中し、チェックや運搬などの定型作業は機械に任せる。これがCI/CDの思想です。

自動化がもたらす変化

最初は設定に少し手間がかかりますが、一度導入してしまえば、開発チームにとって心強い味方になります。

  • クリエイティブな時間の創出:
    第1回の記事（自動化による時短効果）でも紹介した通り、手動作業を自動化することで作業時間は 50〜80%削減 されると言われています（出典：State of DevOps Report）。
    例えば、1回30分のデプロイ作業を年100回行うと、年間で約50時間になります。自動化によってこの時間をほぼゼロにできれば、その分を新機能の開発やスキルアップなど、より価値のある活動に充てることができるようになります。
  • プレッシャーからの解放と属人化の解消:
    「手順書通りに正確に操作しなきゃ…」という緊張感や、「このデプロイ作業は詳しいAさんしかできない」といった属人化は、チームにとって大きなリスクです。
    決まった手順を機械に任せることで、人為的なミスをゼロにし、誰でも安全にリリースできる体制が整います。結果として、担当者の精神的な負担も大きく軽減されます。

2. GitHub Actionsの仕組み

GitHub Actionsは、GitHubに標準搭載されているCI/CDツールです。
リポジトリの中に.github/workflows/というフォルダを作り、その中にYAMLファイルを置くだけで動きます。

基本構造

  1. Event（いつ）: プッシュされた時？ PRが作られた時？
  2. Job（何を）: Linux環境を立ち上げて、テストを実行する
  3. Steps（手順）: 具体的なコマンド（npm install など）

3. 実践：テストを自動化してみよう

では、「PRを作成したら自動でテストを実行する」ワークフローを作ってみましょう。

1. サンプルコードの準備

まず、自動テストの対象となるプログラムが必要です。練習用に「足し算プログラム」と「テストコード」を作成し、リポジトリにコミットしてください。

① package.json （設定ファイル） npm test でテストが動くように設定します。

{
  "name": "my-first-project",
  "version": "1.0.0",
  "scripts": {
    "test": "jest"
  },
  "devDependencies": {
    "jest": "^29.7.0"
  }
}

② sum.js （テスト対象のコード）

function sum(a, b) {
  return a + b;
}
module.exports = sum;

③ sum.test.js （テストコード）

const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

これら3つのファイルを main ブランチにコミットしておきます。

2. ワークフローファイルの作成

リポジトリの「Actions」タブをクリックし、「New workflow」を選択します。
「Node.js」や「Python」など、言語に合わせたテンプレートが表示されますが、今回は「set up a workflow yourself」を選んで、一から書いてみます。

actions-tab.png

3. YAMLの記述

以下のコードをコピーして貼り付け、test.yml という名前で保存（コミット）してください。

name: Run Tests

# いつ実行するか：mainへのPush時と、PR作成時
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    # どのOSで動かすか（通常はubuntu-latestでOK）
    runs-on: ubuntu-latest

    steps:
    # 1. リポジトリのコードをチェックアウト（持ってくる）
    - uses: actions/checkout@v4
    
    # 2. Node.jsのセットアップ
    - name: Use Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        
    # 3. 依存ライブラリのインストール
    - name: Install dependencies
      run: npm install
      
    # 4. テストの実行
    - name: Run test
      run: npm test

4. 動作確認

わざとテストが失敗するようにコードを修正（例：sum.js を return a + b + 1; に変更）し、PRを出してみてください。
PRの画面下部に「All checks have failed」と赤く表示され、詳細を見るとどのテストが落ちたか分かります。

ここで、前回（No.7）紹介した 「ブランチ保護ルール」 が活きてきます。
「Require status checks to pass」を有効にしておけば、テストが失敗しているPRはマージボタンが押せなくなります。
これにより、「うっかりバグのあるコードをマージしてしまった」という事故をシステム的に防ぐことができるのです。

ci-error.png

5. マーケットプレイスの活用

YAMLファイルに出てきた uses: actions/checkout@v4 とは何でしょうか？
これは、世界中の開発者が作ってくれた「便利な機能のパッケージ」です。

GitHub Marketplaceには、数千種類のActionsが公開されています。

  • AWS / Azure / Google Cloudへのデプロイ
  • Slackへの通知
  • Dockerイメージのビルド

これらを組み合わせることで、複雑な処理もパズルのように組み立てられます。
「やりたいこと + GitHub Actions」で検索すれば、たいていのソリューションが見つかります。

github-marketplace.png

6. デプロイの自動化（CD）とシークレット管理

テスト（CI）ができたら、次はデプロイ（CD）です。
デプロイの設定は、テストとは別のファイル（例：deploy.yml）に分けると管理しやすくなります。

トリガーで制御する

デプロイは「PRの作成時」には実行したくありません。「mainブランチにマージされた（Pushされた）時」だけ 実行したいですよね。
その場合、on の書き方を以下のように指定するだけで制御できます。

name: Deploy to Production

# トリガー：mainブランチへのPush時のみ実行
on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: ./deploy.sh
        env:
          # 秘密鍵などはコードに直接書かず、Secretsから読み込む
          API_KEY: ${{ secrets.PROD_API_KEY }}

これで、PR作成時にはこのワークフローは無視され、マージされた時だけデプロイが走るようになります。

【重要】パスワードや鍵の管理（Secrets）

上記のコードにある ${{ secrets.PROD_API_KEY }} とは何でしょうか？
APIキーやパスワードをコード（YAMLファイル）に直接書くと、誰でも見ることができてしまい危険です。

GitHubには、これらを安全に保管する「Secrets（シークレット）」という機能があります。

  1. リポジトリの Settings を開く
  2. 左メニューの Secrets and variables > Actions をクリック
  3. New repository secret ボタンをクリック
  4. Nameに PROD_API_KEY、Secretに実際のキーを入力して保存

こうして保存した情報は暗号化され、GitHub Actionsの実行中だけ安全に取り出すことができます。

secrets.png

まとめ

今回は、GitHub Actionsを使った自動化について解説しました。

  1. CI/CD: テストとデプロイを自動化し、人間は開発に集中する
  2. YAML設定: .github/workflows に置くだけで動き出す
  3. 品質保証: ブランチ保護ルールと組み合わせ、バグの混入を物理的に防ぐ
  4. Secrets: パスワードなどの機密情報は、専用の管理機能を使って安全に扱う

自動化によって開発のスピードと品質は担保されました。
しかし、コードの中に「脆弱性のあるライブラリ」が含まれていたらどうなるでしょうか？
次回は、GitHubが提供する強力なセキュリティ機能「Dependabot」と「Code Scanning」について解説します。

12
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?