「CI/CD」は、コードの変更をきっかけにテストや公開（デプロイ）を自動で実行し、ソフトウェアを素早く安全に届けるための仕組みです。
CIでは変更のたびに自動テストで不具合を早期に見つけ、CDではテストに合格した変更をリリースや本番環境への公開まで自動で進められます。
チーム開発での品質管理はもちろん、個人開発やポートフォリオの更新作業を効率化したい場面でも役立ちます。
本記事では、CI/CDの基本を解説したうえで、GitHub Actionsを使って「pushするとテストが動き、成功したらWebページが自動で公開される」流れを実際の画面とあわせて紹介します。
CI/CDとは
CI/CDとは、ソフトウェアの開発からテスト、リリースまでの作業を自動化し、継続的にソフトウェアを改善・提供するための考え方や仕組みです。
CIは「Continuous Integration（継続的インテグレーション）」、CDは「Continuous Delivery（継続的デリバリー）」または「Continuous Deployment（継続的デプロイ）」を意味します。
CI/CDは、開発チームと運用チームが連携して素早く安全にリリースする「DevOps」を支える代表的な取り組みでもあります。
DevOpsとは？【入門】アジャイル開発との違い、メリットを解説
▶
CI（継続的インテグレーション）とは
CIとは、開発者が作成・変更したコードを共有リポジトリ（コードを保存・共有する場所）に統合する際に、ビルドやテストなどを自動的に実行する仕組みです。
複数の開発者が同じソフトウェアを開発する場合、それぞれの変更をまとめたときに、コード同士が競合したり、既存の機能に不具合が発生したりすることがあります。
変更を長期間統合せずに開発を進めると、問題が発生した箇所を特定することも難しくなります。
CIでは、コードをリポジトリにpush（送信）したときなどにテストを実行し、変更によって不具合が発生していないかを早い段階で確認します。
これにより、不具合の早期発見や修正にかかる負担の軽減が期待できます。
CD（継続的デリバリー/継続的デプロイ）とは
CDには、継続的デリバリーと継続的デプロイという2つの意味があります。
どちらもCIの後に続く工程で、テストなどを通過したソフトウェアをリリースできる状態にする、または実際に公開するまでの作業を自動化します。
継続的デリバリー（Continuous Delivery）は、変更されたコードを自動でビルド・テストし、いつでもリリースできる状態に保つことを目指します。
本番環境への公開は、担当者の承認や手動操作をきっかけに行います。
一方、継続的デプロイ（Continuous Deployment）は、テストなどの条件を満たした変更を、本番環境へ自動的にデプロイ（公開）する仕組みです。
所定の検証を通過すれば、人によるリリース操作を挟まずに公開されます。
両者の違いは、本番環境へ公開する前に、人による判断や操作を挟むかどうかにあります。
CIを含めた3つの違いを整理すると、次のとおりです。
| 種類 | 自動化する範囲 | 本番環境への公開 |
|---|---|---|
| CI（継続的インテグレーション） | コードの統合時のビルド・テスト | 対象外 |
| 継続的デリバリー | CI＋いつでもリリースできる状態にするまで | 人が判断・操作して公開 |
| 継続的デプロイ | CI＋本番環境への公開まで | テストに合格すれば自動で公開 |
本記事の実践では、3章でCI（テストの自動実行）を作成し、4章でテストに合格した変更をGitHub Pagesへ自動公開する継続的デプロイの構成に発展させます。
デプロイとは【3分でわかる】ビルドやリリースとの違い｜IT用語
▶
CI/CDパイプラインの流れ
CI/CDパイプラインとは、コードの変更からテスト、デプロイまでの一連の処理を、あらかじめ定義した順序で実行する仕組みです。
一般的なCI/CDパイプラインは、次のような流れで構成されます。
- コードを変更する：開発者が機能の追加や不具合の修正を行います。
- リポジトリにpushする：変更したコードをGitHubなどのリポジトリに送信します。
- 自動テストを実行する：テストやビルドを実行し、問題がないか確認します。
- 結果を判定する：テストが失敗した場合は処理を停止し、成功した場合は次の工程へ進みます。
- デプロイする：条件を満たしたコードをWebサーバーなどに配置し、利用できる状態にします。
これらの作業を手作業で行う場合とCI/CDで自動化した場合を比べると、次のような違いがあります。
| 作業 | 手作業の場合 | CI/CDで自動化した場合 |
|---|---|---|
| テスト | 担当者が実行するため、実行忘れや確認漏れが起こりやすい | pushのたびに同じ手順で必ず実行される |
| 不具合の発見 | まとめて確認すると、どの変更が原因か特定しにくい | 変更ごとに結果が残るため、原因を絞り込みやすい |
| デプロイ | ファイルの配置ミスや更新漏れが起こりやすい | 決められた手順で毎回同じように公開される |
| 作業の記録 | 誰がいつ何をしたかが残りにくい | 実行履歴とログが自動で残る |
このような仕組みを導入することで、コードの変更から公開までの作業を効率化できます。
ただし、実際の工程や順序は、プロジェクトの規模や採用するツールによって異なります。
GitHub ActionsでCI/CDを実践するための準備
ここからは、GitHubが提供する自動化機能「GitHub Actions」を使い、CI/CDの仕組みを実践していきます。
今回は、簡単なWebサイトに対して自動テストを実行し、テストに合格した場合にGitHub Pages（GitHubが提供する無料のWebサイト公開機能）で公開する構成を作成します。
必要なものと事前準備
今回の実践で必要なものは、以下の2つです。
- GitHubアカウント（無料のGitHub Freeプランで可）
- Webブラウザー
GitHubアカウントをお持ちでない場合は、事前に登録が必要です。
登録方法はGitHubでのアカウントの作成（GitHub公式ドキュメント）を参照してください。
今回はGitHub上のファイル編集機能を利用するため、ローカル環境（自分のPC）への開発ツールのインストールは必須ではありません。
テストの実行に必要なNode.jsも、GitHub Actionsの実行環境に自動でセットアップします。
また、今回のようにパブリック（公開）リポジトリで標準の実行環境を使う場合、GitHub Actionsは無料で利用できます（料金の詳細は5章で解説します）。
【画像付き】GitHubの使い方｜設定・基本操作
▶
リポジトリを作成する
まずは、実践で使用するリポジトリを作成します。
GitHubにログインし、画面右上の「＋」メニューから「New repository」を選択します。
作成画面が表示されたら、次のように設定し、「Create repository」をクリックしてリポジトリを作成します。
| 項目 | 設定値 | 説明 |
|---|---|---|
| Repository name | ci-cd-practice | リポジトリ名（任意の名前で可） |
| Choose visibility | Public | リポジトリの公開範囲 |
| Add README | On | READMEファイルを作成し、mainブランチが用意された状態で始める |
今回は、GitHub PagesでWebサイトを公開するため、Publicリポジトリを使用します。
GitHub Freeプランの場合、GitHub Pagesを利用できるのはパブリックリポジトリのみです。
公開したWebサイトは誰でも閲覧できるため、パスワードなどの機密情報は含めないようにしましょう。
【CI】pushするたびにテストを自動実行する
GitHub Actionsでは、「ワークフロー」と呼ばれる設定ファイルを作成することで、特定の操作をきっかけに処理を自動実行できます。
この章では、リポジトリへのpushをきっかけにJavaScriptのテストを実行するワークフローを作成します。
なお、この章で自動化するのはテストの実行（CI）までで、Webサイトの公開はまだ行いません。
テスト対象のコードとテストを追加する
まずは、テスト対象となるJavaScriptファイルと、動作を確認するためのテストファイルを用意します。
今回は、2つの数値を足し算する簡単な関数を作成し、計算結果が正しいかをテストします。
GitHubのリポジトリ画面で「Add file」から「Create new file」を選択し、ファイル名に「sum.js」と入力して、以下のコードを記述します。
function sum(a, b) {
return a + b;
}
if (typeof module !== "undefined") {
module.exports = { sum };
}
後半のif文は、作成したsum関数をテストファイルなど別のファイルから読み込めるようにするための記述です。
コードを入力したら、画面右上の「Commit changes…」をクリックします。
表示されたダイアログで「Commit directly to the main branch」が選択されていることを確認し、「Commit changes」をクリックして保存します。
続いて、同じ手順で「test.js」というファイルを作成し、以下のコードを記述してコミットします。
const { sum } = require("./sum");
function testSum() {
const result = sum(2, 3);
if (result !== 5) {
throw new Error(
`Expected 5, but got ${result}`
);
}
console.log("Test passed!");
}
testSum();
このテストでは、sum(2, 3)の結果が5であれば「Test passed!」と表示し、5以外であればエラーを発生させます。
エラーが発生するとプログラムが異常終了するため、GitHub Actionsはこれを「テスト失敗」として扱います。
これで、テスト対象のコードとテストコードの用意は完了です。
ワークフローファイル（YAML）を作成する
次に、GitHub Actionsにテストの実行方法を指示するワークフローファイルを作成します。
「Add file」から「Create new file」を選択し、ファイル名に「.github/workflows/ci.yml」と入力します。
ファイル名の欄に「/」を入力すると、自動的にフォルダーとして区切られ、.githubフォルダーとworkflowsフォルダーがまとめて作成されます。
GitHub Actionsでは、.github/workflows/ディレクトリ内にYAML形式（.ymlまたは.yaml）のファイルを配置することで、ワークフローを定義できます。
YAMLは、インデント（行頭の空白）で設定の階層を表すテキスト形式です。
以下のコードを記述してください。
name: CI Test
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v6
- name: Set up Node.js
uses: actions/setup-node@v7
with:
node-version: 22
- name: Run tests
run: node test.js
インデントは半角スペース2つずつで揃え、タブ文字は使わないようにしましょう。
インデントがずれると、ワークフローが正しく読み込まれません。
それぞれの設定内容は以下のとおりです。
| 設定項目 | 意味 |
|---|---|
| name | ワークフロー名（Actionsタブに表示される名前） |
| on | ワークフローの実行タイミング（今回はmainブランチへのpushをきっかけに実行） |
| jobs | 実行する処理のまとまり（ジョブ）を定義する。今回は「test」というジョブを1つ定義 |
| runs-on | ジョブを実行する環境。ubuntu-latestは、GitHubが提供するUbuntuの実行環境（ランナー）を使用する設定 |
| steps | ジョブ内で実行する処理を、上から順に定義する |
| actions/checkout@v6 | リポジトリのコードを実行環境に取得する |
| actions/setup-node@v7 | 指定したバージョン（今回は22）のNode.jsを実行環境にセットアップする |
| run | 指定したコマンドを実行する（今回はnode test.jsでテストを実行） |
なお、branchesにmainを指定しているため、今回のワークフローはmainブランチへのpushで実行されます。
別のブランチ名を使用している場合は、実際のブランチ名に合わせて変更してください。
書き方の詳細は、ワークフロー構文（GitHub公式ドキュメント）で確認できます。
設定を入力したら、「Commit changes」をクリックして保存します。
このコミットもmainブランチへのpushとして扱われるため、保存した時点でワークフローが実行されます。
Actionsタブで実行結果を確認する
ワークフローファイルを保存したら、リポジトリ上部の「Actions」タブを開きます。
ワークフローが正常に認識されていれば、左側のメニューに「CI Test」が表示され、一覧にコミットメッセージ（ここでは「Create ci.yml」）の名前で実行履歴が追加されます。
成功すると緑のチェックマーク、失敗すると赤いバツ印が表示されます。
実行履歴をクリックし、左側の「test」ジョブを選択すると、各ステップの処理状況やログを確認できます。
「Run tests」のステップを開き、次のように表示されていればテストは成功です。
Test passed!ログの見方は、ワークフロー実行ログの使用（GitHub公式ドキュメント）も参考にしてください。
わざとテストを失敗させてCIの役割を確かめる
次に、テスト対象のコードに問題がある場合、CIがどのように動作するのかを確認しましょう。
リポジトリの「sum.js」を開き、右上の鉛筆アイコンから編集画面を開いて、足し算（a + b）を引き算（a – b）に変更します。
function sum(a, b) {
return a - b;
}
if (typeof module !== "undefined") {
module.exports = { sum };
}変更をコミットすると、mainブランチへのpushをきっかけにGitHub Actionsが再び実行されます。
今回のコードでは、sum(2, 3)の結果が-1になるため、テストで期待値の5と一致せず、エラーが発生します。
失敗した実行履歴を選択し、「test」ジョブを確認すると、「Run tests」のステップで失敗していることがわかります。
/home/runner/work/ci-cd-practice/ci-cd-practice/test.js:7
throw new Error(
^
Error: Expected 5, but got -1
at testSum (/home/runner/work/ci-cd-practice/ci-cd-practice/test.js:7:11)
（中略）
Node.js v22.23.3
Error: Process completed with exit code 1.ログでは、「Error: Expected 5, but got -1」の行に注目します。
test.jsで用意したエラーメッセージで、期待値5に対して結果が-1だったことを示しています。
最終行の「exit code 1」はコマンドが異常終了したことを表し、GitHub Actionsはこれを受けてステップを失敗と判定しています。
このように、CIではコードの変更によって発生した問題を自動で検知できます。
テストが失敗した場合は、ログから原因を確認し、コードを修正して再度テストを実行することが重要です。
確認が終わったら、sum.jsを元のコード（a + b）に戻してコミットし、Actionsタブでテストが再び成功することを確認しておきましょう。
コードを戻さないまま次の章に進むと、テストが失敗してWebサイトが公開されません。
【CD】テストが通ったら自動でWebサイトを公開する
この章では、3章で作成したCIのワークフローにデプロイの処理を追加し、テストに合格した変更をGitHub Pagesへ自動で公開します。
mainブランチへのpushから公開までを人の操作なしで行うため、継続的デプロイにあたる構成です。
GitHub Pagesの公開元を「GitHub Actions」に設定する
まずは、Webサイトを公開するための設定を行います。
リポジトリの「Settings」タブを選択し、左側のメニューから「Pages」を開きます。
設定画面を開いたら、「Build and deployment」の「Source」から、「GitHub Actions」を選択します。
これで、GitHub Actionsを通じてWebサイトを公開できるようになります。
画面に表示される「Static HTML」などのテンプレートは使用しないため、「Configure」をクリックする必要はありません。
詳細は、GitHub Pagesサイトの公開元の設定（GitHub公式ドキュメント）で確認できます。
「テスト→デプロイ」のワークフローに書き換える
次に、3章で作成したワークフローファイル「.github/workflows/ci.yml」を編集します。
今回は、テストに合格した場合にのみGitHub Pagesへのデプロイを実行する構成に変更します。
まず、Webサイトとして表示するHTMLファイルを用意しましょう。
リポジトリで「Add file」から「Create new file」を選択し、ファイル名に「index.html」と入力して、以下のコードを記述します。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CI/CD Practice</title>
</head>
<body>
<h1>CI/CDの実践</h1>
<p>GitHub Actionsによる自動テストと自動デプロイが完了しました。</p>
</body>
</html>
作成したHTMLファイルをコミットして保存したら、続いて「.github/workflows/ci.yml」を開き、鉛筆アイコンから編集画面を開きます。
既存のtestジョブの下に、deployジョブを追加します。
追加後のファイル全体は、次のとおりです。
name: CI Test
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v6
- name: Set up Node.js
uses: actions/setup-node@v7
with:
node-version: 22
- name: Run tests
run: node test.js
# ここから追加（deployジョブ）
deploy:
needs: test
runs-on: ubuntu-latest
permissions:
contents: read
pages: write
id-token: write
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- name: Checkout repository
uses: actions/checkout@v6
- name: Configure GitHub Pages
uses: actions/configure-pages@v6
- name: Upload site artifact
uses: actions/upload-pages-artifact@v5
with:
path: .
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v5このワークフローでは、テストとデプロイを別々のジョブとして定義しています。
追加した主な設定の意味は、次のとおりです。
| 設定項目 | 意味 |
|---|---|
| needs: test | testジョブが成功した場合にのみ、deployジョブを実行する |
| permissions | ワークフローに与える権限。GitHub Pagesへのデプロイには、pages: writeとid-token: writeが必要 |
| environment | デプロイ先の環境。github-pagesを指定し、公開URLを実行結果に表示する |
| actions/configure-pages@v6 | GitHub Pagesの設定情報を読み込む |
| actions/upload-pages-artifact@v5 | 公開するファイルをまとめてアップロードする。path: .はリポジトリ直下のファイルを対象にする設定（.githubフォルダーなどは自動で除外される） |
| actions/deploy-pages@v5 | アップロードしたファイルをGitHub Pagesに公開する |
特に重要なのは、needs: testの設定です。
この指定により、テストが成功しなければデプロイのジョブは実行されないようになっています。
各設定の詳細は、GitHub Pagesでのカスタムワークフローの使用（GitHub公式ドキュメント）で確認できます。
編集が完了したら、「Commit changes」をクリックして保存します。
このコミットをきっかけに、書き換えたワークフローがすぐに実行されます。
公開URLで動作を確認する
ワークフローの書き換えが完了したら、「Actions」タブを開いて最新の実行履歴を選択し、testとdeployの両方のジョブが成功しているかを確認してください。
ジョブが無事に成功していれば、以下のようにtestからdeployへ線でつながった図が表示され、deployの下に公開されたWebサイトのURLが表示されます。
URLは「https://ユーザー名.github.io/リポジトリ名/」の形式です。
表示されたURLにアクセスし、作成したHTMLファイルの内容が表示されていれば成功です。
なお、テストが失敗した場合は、deployジョブが実行されないため、新しい変更はデプロイされません。
試しに、3章と同じようにsum.jsを引き算に変更してコミットすると、testジョブが失敗し、deployジョブはスキップ（斜線のアイコン）されます。
確認後は、sum.jsを元のコードに戻しておきましょう。
このように、CIとCDを連携させることで、コードの検証から公開までを一連の流れとして自動化できます。
うまく動かないときの確認ポイント
手順どおりに進めてもワークフローが動かない場合は、次の点を確認してください。
| 症状 | 主な原因と対処法 |
|---|---|
| Actionsタブに実行履歴が表示されない | ファイルの場所が「.github/workflows/」になっているか、拡張子が「.yml」か、branchesの指定が実際のブランチ名と一致しているかを確認する |
| ワークフローファイルのエラーが表示される | インデントのずれやタブ文字の混入が多い原因。本記事のコードをコピーして貼り付け直す |
| Run testsのステップで失敗する | ログの「Error:」の行を確認し、sum.jsやtest.jsの内容を見直す |
| 「Get Pages site failed」と表示される | Settings→PagesのSourceが「GitHub Actions」になっているかを確認する |
| deployジョブで権限に関するエラーが表示される | deployジョブのpermissionsに、pages: writeとid-token: writeが書かれているかを確認する |
CI/CDのメリットと注意点
CI/CDを導入するメリット
CI/CDを導入する主なメリットは、次の3つです。
- 不具合を早期に発見できる
コードの変更時にテストを自動実行することで、既存機能への影響や想定外の動作を早い段階で検知できます。
問題が発生したタイミングと変更内容を照らし合わせやすくなるため、原因の特定や修正も進めやすくなります。 - 手作業による負担を減らせる
テストやデプロイを手動で行う場合、実行漏れや設定ミスが発生する可能性があります。
CI/CDによって定型作業を自動化すれば、開発者が繰り返し行う作業を減らし、機能開発や品質改善に時間を使いやすくなります。 - リリースを迅速化できる
テストからデプロイまでの流れを自動化することで、公開作業にかかる時間を短縮できます。
小さな変更を継続的にリリースしやすくなるため、利用者からのフィードバックを取り入れながら改善を進められます。
デメリットと導入時の注意点
CI/CDは便利な一方で、導入や運用には手間もかかります。
効果的に活用するために、次の点に注意しましょう。
- テストの品質を確保する
自動テストを導入しても、テスト対象や確認内容が不十分であれば、不具合を見逃す可能性があります。
正常系だけでなく、異常系や境界値なども考慮し、実際のアプリケーションに必要なテストを用意することが重要です。 - ワークフローの保守が必要になる
依存ライブラリや実行環境の変更、外部サービスの仕様変更などによって、ワークフローが正常に動作しなくなる場合があります。
GitHub Actionsでも、利用しているアクションのバージョンが古くなると動作しなくなることがあるため、定期的に見直しましょう。 - 権限や機密情報を適切に管理する
デプロイに必要な認証情報やAPIキーなどはソースコードに直接記入せず、GitHub ActionsのSecretsなどを利用し、必要な処理に限り参照できるようにしておきましょう。
また、ワークフローに付与する権限も必要最小限に設定することが大切です。 - 導入・運用コストを考慮する
自動化には、ワークフローの作成やテストの整備、実行環境の維持などのコストがかかります。
小規模なプロジェクトの場合は、まずテストの自動実行など、効果が大きい部分から導入するとよいでしょう。
GitHub Actionsの無料枠と料金プラン
GitHub Actionsの料金は、リポジトリの公開設定や実行環境、利用するプランによって異なります。
GitHub Actionsの課金（GitHub公式ドキュメント）によると、パブリックリポジトリで標準の実行環境（GitHubホステッドランナー）を使う場合は無料です。
本記事の実践もパブリックリポジトリで行っているため、料金はかかりません。
プライベートリポジトリで利用する場合は、プランごとに次の無料枠が毎月付与されます（2026年10月時点）。
| プラン | 実行時間（1か月あたり） | 成果物ストレージ |
|---|---|---|
| GitHub Free | 2,000分 | 500MB |
| GitHub Pro | 3,000分 | 1GB |
| GitHub Team | 3,000分 | 2GB |
| GitHub Enterprise Cloud | 50,000分 | 50GB |
無料枠を超えた場合は、追加の利用分に料金が発生します。
支払い方法を登録していない場合は、無料枠を使い切った時点で利用がブロックされるため、利用状況を確認しておくことが重要です。
主なCI/CDツールの比較と選び方
CI/CDを実現するツールには、GitHub Actions以外にもさまざまな選択肢があります。
以下は、代表的なツールの一例です。
| ツール | 特徴 | 向いているケース |
|---|---|---|
| GitHub Actions | GitHubに統合されており、リポジトリ内のYAMLファイルでワークフローを管理できる | GitHubでソースコードを管理している場合 |
| GitLab CI/CD | GitLabに統合されており、パイプラインやジョブをまとめて管理できる | GitLabでソースコード管理からCI/CDまで運用したい場合 |
| Jenkins | プラグインによる拡張性が高く、実行環境を柔軟に構築できる | 独自の要件や既存の開発環境に合わせて細かく構成したい場合 |
| CircleCI | CI/CD向けの実行環境やワークフロー管理機能を提供する | ビルドやテストを効率的に自動化したい場合 |
ツールを選ぶ際は、既存のソースコード管理サービスとの相性、必要な機能、運用のしやすさ、料金などを比較することが大切です。
既に利用しているサービスとの連携を重視する場合は、そのサービスに統合されたCI/CD機能から検討するとよいでしょう。
CI/CDに関するよくある質問
Q. CIとCDは必ずセットで導入する必要がありますか？
A. 必ずしもセットで導入する必要はありません。
まずはCIによる自動テストから始め、テストやリリースの運用が整ってきた段階でCDを導入する方法もあります。
特に、公開前に人の確認が必要なプロジェクトでは、テストだけを自動化し、デプロイは人が確認してから実行する構成も有効です。
Q. テストに失敗した場合、コードは自動的に元に戻りますか？
A. 通常、テストが失敗しても、リポジトリにコミットされたコードが自動的に取り消されるわけではありません。
CI/CDのワークフローでは、失敗したジョブの後続処理を停止するのが一般的です。
不具合のあるコードがmainブランチに入ること自体を防ぎたい場合は、ブランチ保護ルールやプルリクエストの必須チェックなどを組み合わせて設定します。
Q. GitHub Actionsを使うために、ローカル環境の構築は必要ですか？
A. 必須ではありません。
ただし、実際の開発ではローカル環境でコードを実行・検証してからpushする運用も一般的です。
ローカルとCIの実行環境（Node.jsのバージョンなど）をできるだけ一致させると、環境の違いによる問題を減らしやすくなります。
Q. GitHub Pages以外へのデプロイも自動化できますか？
A. 可能です。
GitHub Actionsは、さまざまなクラウドサービスやホスティングサービスと連携できます。
ただし、デプロイ先によって必要な設定や認証方法が異なるため、利用するサービスの公式ドキュメントを確認し、認証情報や権限を適切に設定することが重要です。
また、VercelのようにGitHubと連携するだけでpush時の自動デプロイを行えるサービスもあります。
Vercelとは？Webサイトをデプロイする方法を初心者向けに実践解説
▶
まとめ
CI/CDは、ソフトウェアのテストやリリースに関する作業を自動化し、開発の効率化と品質の維持を支援する仕組みです。
本記事では、GitHub Actionsを使って、pushをきっかけにテストを実行するCIと、テストに合格した変更をGitHub Pagesへ自動公開する継続的デプロイを実践しました。
CI/CDを導入する際は、すべての工程を一度に自動化するのではなく、まずはテストの自動実行など、取り組みやすい部分から始めることが大切です。
プロジェクトの規模や要件に合わせて段階的に自動化を進めることで、継続的に改善できる開発環境を整えやすくなります。
