CI/CD 自動化

🎯 コアとなる問い

コードはローカルで問題なく動いているが、世界中の人がアクセスできるようにするにはどうすればよいか？

1. なぜ「サービスを公開」する必要があるのか？

自分の家で美味しい料理を作ったと想像してみてください。とても美味しい。でも問題は、自分の家族しか味わえないということです。近所の人、警備員、見知らぬ人は誰も味わえません。

どうすればよいでしょうか？料理をレストランに持っていく必要があります。これが「サービスの公開（デプロイ）」がやることです——あなたが書いたコードを、個人のパソコンから、24時間365日稼働し続ける「公共のコンピュータ」に移すのです。これにより、インターネットに接続できる人なら誰でもウェブサイトにアクセスできるようになります。

服务上线全流程从代码到用户眼中的网页

开发阶段

Git

代码版本控制

→

CI/CD

自动化流水线

构建阶段

Test

自动化测试

→

Build

编译打包

→

Artifact

构建产物存储

部署阶段

Server

服务器环境

→

Deploy

部署应用

→

Nginx

反向代理

网络配置

HTTPS

SSL证书

→

CDN

内容分发加速

→

DNS

域名解析

运维阶段

Monitor

监控状态

→

Log

日志收集

→

Alert

告警通知

核心原则：小步快跑 → 先上线MVP → 逐步完善

サービスの公開には多くのステップが含まれます。レストランを開くのが料理を出すだけではないのと同じで、店舗の賃貸、内装、許可証の取得、スタッフの採用なども必要です。ウェブ開発も同様です。コードからユーザーがアクセスできるウェブサイトになるまで、間には多くのステップがあります。ビルド、デプロイ、ネットワーク設定、セキュリティ確保などを段階的に完了させる必要があります。

以下、全プロセスを分解して説明します。各ステップを細かく丁寧に説明するので、まったくの初心者でも理解できるようにします。

2. ビルド：コードを「持ち運び可能なパッケージ」に変える

2.1 なぜビルドが必要なのか？

初心者はよくこう聞きます：コードが書けたのに、なぜそのままサーバーに置いてユーザーにアクセスさせられないのか？

この質問に答えるには、まずあなたが書いたコードがどのような形式なのかを理解する必要があります。Vue、React、Express、Koa などのフレームワークを使っているかもしれません。これらのフレームワークには共通の特徴があります：ブラウザやサーバーが直接使用することを意図したものではないということです。

例えば、Vue のコードを書くとき、<template> や <script setup> というタグを使ったことがありませんか？この構文を理解できるのは Vue だけです。ブラウザはまったく理解できません。ブラウザが理解できるのは 3 つの言語だけです：HTML（ウェブページの構造）、CSS（ウェブページのスタイル）、JavaScript（ウェブページのロジック）です。Vue コンポーネントの構文はブラウザにとって暗号のようなもので、まったく理解できません。

そのため、コードをサーバーに置く前に、重要なことをしなければなりません：ブラウザが理解できる言語に翻訳することです。この翻訳プロセスが「ビルド（Build）」と呼ばれます。

2.2 ビルドは具体的に何をするのか？

ビルドは単なる翻訳ではありません。ウェブサイトをより速く、よりリソース効率よく実行するための多くの最適化も行います。具体的に何をしているのか詳しく見ていきましょう：

ステップ1：依存関係の解決

コードを書くとき、Vue、Vue Router、Axios、Vite などの様々なサードパーティライブラリを使用します。これらのライブラリを毎回ユーザーに npm からダウンロードさせるわけにはいきません——遅すぎます。ビルドツールはコードを分析し、すべての依存関係を見つけ出し、それらを「バンドル」します。

ステップ2：コンパイルと変換

これが最も重要なステップです。Vue コンポーネントを HTML と JavaScript にコンパイルします。SASS/LESS を CSS にコンパイルします。ES6+ の新しい構文を互換性の高い ES5 コードに変換します。このステップが完了すると、コードは「開発者が読める形式」から「機械が実行できる形式」になります。

ステップ3：圧縮と難読化

圧縮はすべての空白、改行、コメントを削除します。変数名を英単語から1文字に変更します。例えば、userName は a に、calculateTotalPrice は b になります。これによりファイルサイズが大幅に削減され、ユーザーのダウンロードが速くなります。難読化されたコードは人間にはほぼ読めず、「コードの保護」という役割も果たします。

ステップ4：コード分割

10個のページを書いたとします。各ページには独自のコードがあります。しかし、ユーザーはそのうちの1つのページにしかアクセスしないかもしれません。なぜ他の9つのページのコードをダウンロードする必要があるのでしょうか？ビルドツールはコードを複数のチャンクに分割します。ユーザーがアクセスしたページのコードだけをダウンロードします。これが「遅延読み込み」で、初回アクセスの速度を大幅に向上させます。

ステップ5：ハッシュの生成

これは非常に重要なステップですが、多くの人が見落とします。ビルドが完了すると、ファイル名が app.abc123.js や vendor.def456.css のような形式になります。末尾の英数字の文字列が「ハッシュ」です。

ハッシュの役割は次の通りです：コードに何らかの変更があると、ハッシュ値が変わります。ブラウザは「このファイルが変更された、再ダウンロードが必要だ」と認識します。変更のないファイルは、ブラウザがキャッシュを引き続き使用します。再ダウンロードは不要です。これにより、ユーザーが常に最新のコードを見られることを保証しつつ、キャッシュを最大限に活用して速度を向上させます。

1解析依赖

→

2编译转换

→

3打包压缩

→

4完成

2.3 ビルドの実行方法

最近のフロントエンドプロジェクトのほとんどは、ビルドツールがすでに設定されています。次のコマンドを覚えておけば大丈夫です：

bash

# npm を使う場合
npm run build

# yarn を使う場合
yarn build

# pnpm を使う場合
pnpm build

実行後、プロジェクトのルートディレクトリにある dist フォルダ（build や .output と呼ばれることもあります）を探してください。中にビルドされたすべてのファイルが含まれています。これらが最終的にサーバーにアップロードするファイルです。追加の変更は不要です。そのままサーバーに配置するだけです。

2.4 ビルド成果物には何が含まれているか？

dist フォルダを開くと、主に3種類のファイルがあります：

HTML ファイル：通常 index.html と呼ばれます。これがエントリファイルで、ブラウザが最初に読み込むものです。
JS ファイル：すべての JavaScript コード。1つの場合も複数の場合もあります。
CSS ファイル：すべてのスタイルコード。HTML 内にインライン化されている場合も、独立した CSS ファイルの場合もあります。

より複雑なバックエンドプロジェクト（Node.js など）の場合、ビルド成果物は実行可能ファイルや Docker イメージの可能性があります。しかし原理は同じです：コードをサーバーが直接実行できる形式に変えます。

3. サーバー：決して閉まらない「家」を見つける

3.1 サーバーとは何か？

「サーバー」という言葉を初めて聞いたとき、何か高価で神秘的な装置を想像する人が多いです。実際にはそれほど複雑ではありません。サーバーとはコンピュータです。決してシャットダウンせず、常にインターネットに接続されているコンピュータです。

「家にパソコンがあるのに、なぜ追加でサーバーを借りる必要があるのか？」と聞く人もいるでしょう。

良い質問です。分析してみましょう：

まず、家庭用のパソコンは24時間稼働させられません。外出する必要もあれば、寝る必要もありますし、時にはフリーズして再起動することもあります。しかしサーバーは違います。この目的のために特別に設計されており、365日年中無休で稼働できます。ウェブサイトはいつでもアクセス可能です。

次に、家庭のネットワークも十分ではありません。家庭用ブロードバンドのアップロード速度は通常遅いです。また、家庭用ブロードバンドの IP アドレスは動的に変化します。今日はこの IP で、明日は別の IP になっているかもしれません。ウェブサイトのサーバーとしては使えません。サーバーはデータセンターの高速ネットワークを使用し、固定 IP で非常に高速です。

第三に、家庭のパソコンには「パブリック IP」がありません。パブリック IP とは何か？世界的に一意のアドレスです。このアドレスがあって初めて、他の人がインターネット上であなたのコンピュータを見つけられます。家庭のパソコンの IP アドレスは通常、家庭のローカルネットワーク内でしか使えません。外部の人はあなたを見つけられません。サーバーは異なります。固定のパブリック IP を持ち、世界中の人がこの IP を通じて見つけられます。

个人博客1核 1G¥50/月

小型电商2核 4G¥300/月

中型应用4核 8G¥1000/月

3.2 サーバーの選び方

サーバーを選ぶ際、主に3つの指標を見ます：CPU コア数、メモリ容量、ディスク容量。この3つの指標が高いほど、サーバーのパフォーマンスが良く、価格も高くなります。

初心者には、高価な構成を買う必要はまったくありません。この簡単なガイドラインを覚えておいてください：

個人プロジェクト、学習・練習：1コア 2GB メモリで十分。月額数十元程度。
小規模ビジネスプロジェクト：2コア 4GB メモリ。1日数千から数万のアクセスに対応可能。
中規模プロジェクト：4コア 8GB 以上。専門の運用チームが必要になります。

もう一つ考慮すべき点：ロケーション。ユーザーが主に中国にいる場合、国内サーバー（Alibaba Cloud、Tencent Cloud）を選ぶとアクセスが速いです。ユーザーが主に海外にいる場合、海外のサーバー（AWS、Google Cloud、DigitalOcean）または香港のサーバーを選んでください。速度が速く、ICP 申請も不要です。

3.4 主要クラウドプロバイダーの比較

プロバイダー	対象ユーザー	特徴	新規ユーザー価格
Alibaba Cloud	国内ビジネス	最大の市場シェア、包括的なエコシステム	初年度数十～100元以上
Tencent Cloud	ミニプログラム、ゲーム	ミニプログラムのクラウド開発サポートが良好	初年度の割引が大きい
Huawei Cloud	企業ユーザー	政府・政務プロジェクトの首选	価格はやや高め
DigitalOcean	開発者	シンプルで使いやすい、価格が透明	$4/月から
Vercel	フロントエンドプロジェクト	ゼロ設定、プッシュするだけでデプロイ	無料枠で十分

初心者には Alibaba Cloud または Tencent Cloud の学生・新規ユーザー割引が最もお勧めです。通常、年間数十元だけで済みます。コストパフォーマンスが非常に高いです。純粋なフロントエンドプロジェクトで手間を省きたい場合は、Vercel や Netlify を直接使うこともできます。サーバーを買う必要すらありません。コードをプッシュするだけで自動的にデプロイされます。

3.5 サーバーを取得した後は何をすべきか？

サーバーを購入した後、いくつかの重要な情報が記載されたメールが届きます：

IP アドレス：123.45.67.89 のような数字の文字列。インターネット上のサーバーの所在地です。
ログインユーザー名：通常 root（管理者アカウント）。
ログインパスワード：初期パスワード、またはパスワードを設定するためのリンク。

この情報があれば、SSH（Secure Shell） を使用してリモートでサーバーにログインし、設定を行うことができます。SSH は、遠く離れたサーバーを自分のパソコンから操作できる、暗号化されたリモートコントロールコマンドのようなものです。

ログインコマンドは次のようになります：

bash

ssh root@123.45.67.89
# Enter キーを押すとパスワードの入力を求められます。正しいパスワードを入力するとログイン成功です。

ログインに成功すると、サーバーのコマンドラインインターフェースに入ります。自分のパソコンでターミナルウィンドウを開いたような画面です。ここでソフトウェアのインストール、フォルダの作成、設定の変更ができます。すべての操作はローカルコンピュータと同じです。

4. デプロイ：コードを「家」に搬入する

4.1 デプロイとは何か？

デプロイとは、サーバー（家）を借りた後、コード（家具や荷物）を搬入し、ドアを開けて営業を開始するプロセスです。

具体的には、デプロイには次のステップが含まれます：

コードをサーバーにアップロード：ビルド成果物をローカルコンピュータからサーバーに転送する。
依存関係のインストール：サーバーにプロジェクトに必要なパッケージがない可能性があります。インストールが必要です。
環境変数の設定：データベースのパスワードや API キーなどの機密情報。
サービスの起動：アプリケーションを実行し、ユーザーのリクエストの待ち受けを開始する。

これら4つのステップは複雑に聞こえますが、実際にはそれほど難しくありません。以下で各ステップを詳しく説明します。

个人博客1核 1G¥50/月

小型电商2核 4G¥300/月

中型应用4核 8G¥1000/月

4.2 コードをサーバーにアップロードする方法

方法1：FTP/SFTP アップロード

最も直感的な方法です。クラウドストレージのように、ファイルをサーバーにドラッグします。無料ソフトの FileZilla をパソコンにダウンロードし、サーバーの IP、ユーザー名、パスワードを入力すれば、ローカルファイルと同じようにサーバーのファイルを管理できます。

方法2：Git による取得

お勧めの方法です。まず GitHub、GitLab、Gitee にコードリポジトリを作成します。コードをクラウドにプッシュします。その後、サーバー上で git clone コマンドを使用してコードを取得します。

メリットは、後続のコード更新時にサーバー上で git pull コマンドを実行するだけで済むことです。毎回手動でアップロードする必要がありません。また、コードがクラウドに安全に保存されるため、サーバーを再インストールしても問題ありません。

方法3：CI/CD 自動デプロイ

最もプロフェッショナルな方法であり、強くお勧めする方法です。CI/CD（継続的インテグレーション/継続的デプロイ）を設定することで、コードを GitHub にプッシュするだけで済みます。CI/CD システムが自動的に全プロセスを完了します：コードの取得 → 依存関係のインストール → ビルド → デプロイ。サーバーにログインする必要すらありません。すべて自動的に完了します。

4.3 デプロイの具体的なステップ

最もシンプルな方法——Git 手動デプロイを使用して、全プロセスをステップバイステップで説明します：

ステップ1：サーバーに接続

bash

ssh root@123.45.67.89

ステップ2：必要なソフトウェアのインストール

Node.js プロジェクトの場合、まず Node.js をインストールする必要があります：

bash

# Ubuntu システムの場合
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs

ステップ3：コードの取得

bash

# ウェブサイト用のディレクトリを作成
mkdir -p /var/www/my-website
cd /var/www/my-website

# コードリポジトリをクローン（事前に GitHub にリポジトリを作成しておく必要があります）
git clone https://github.com/your-username/your-repo-name.git .

ステップ4：依存関係のインストールとビルド

bash

# プロジェクトの依存関係をインストール
npm install

# プロジェクトをビルド（dist ディレクトリが生成される）
npm run build

ステップ5：PM2 でサービスを起動

なぜ PM2 を使うのか？PM2 はプロセス管理ツールで、ウェブサイトをバックグラウンドで継続的に実行させます。サーバーが再起動しても自動的に起動します。

bash

# PM2 をグローバルにインストール
sudo npm install -g pm2

# ウェブサイトを起動（エントリファイルが index.js の場合）
pm2 start index.js

# 起動時の自動起動を設定
pm2 startup
pm2 save

ステップ6：Nginx リバースプロキシの設定

Node.js アプリケーションは通常、3000 や 8080 などのポートで実行されます。しかし、ユーザーがアクセスするのはポート 80（HTTP のデフォルトポート）です。Nginx を使用して、ポート 80 のリクエストをアプリケーションのポートに転送する必要があります。

bash

# Nginx をインストール
sudo apt install -y nginx

# Nginx 設定ファイルを作成
sudo nano /etc/nginx/sites-available/my-website

開いたエディタに次の設定を記述します：

nginx

server {
    listen 80;
    server_name example.com www.example.com;

    # 静的ファイル（ビルド成果物）を直接返す
    location / {
        root /var/www/my-website/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # API リクエストを Node.js バックエンドに転送
    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

保存して終了した後、この設定を有効にします：

bash

# 設定を有効にする
sudo ln -s /etc/nginx/sites-available/my-website /etc/nginx/sites-enabled/

# 設定にエラーがないかテスト
sudo nginx -t

# Nginx を再起動
sudo systemctl restart nginx

これで http://example.com にアクセスすると（事前にドメインをこのサーバーの IP に向けておいてください）、ウェブサイトが表示されるはずです！

5. ドメインと DNS：ウェブサイトに良い名前を付ける

5.1 なぜドメインを買う必要があるのか？

サーバーの IP があるのに、なぜドメインを買う必要があるのでしょうか？

考えてみてください。123.45.67.89 のような数字の羅列を覚えるのは難しくないですか？打ち間違えやすいでしょう？でも baidu.com や taobao.com のような名前なら簡単に覚えられますよね？

ドメインはウェブサイトの名前です。覚えやすく、プロフェッショナルで、ブランドイメージを反映できます。想像してみてください。「私の作ったウェブサイトにアクセスして、IP は 123.45.67.89 です」と言うのと、「woshishuaige.com にアクセスして」と言うのと、どちらがそれっぽいでしょうか？

💻用户输入域名

→

📋查询 DNS

→

✅返回 IP

示例：example.com → 192.168.1.1

5.2 DNS とは何か？

さて、ドメインを買いました。例えば my-awesome-website.com とします。しかし問題があります：コンピュータは IP アドレスしか理解できず、「my-awesome-website.com」のような人間の言葉は理解できないのです。

ここで DNS が登場します。DNS は「Domain Name System」の略です。「ドメイン名システム」と訳されます。人間が覚えやすいドメイン名を、コンピュータが理解できる IP アドレスに変換する巨大な「電話帳」と考えてください。

ブラウザに my-awesome-website.com と入力して Enter キーを押すと、裏側で次のようなことが起こります：

ブラウザが DNS に聞きます：「ねえ、my-awesome-website.com の IP アドレスは何？」
DNS が「電話帳」を調べて、ブラウザに答えます：「IP は 123.45.67.89 です」
ブラウザがこの IP アドレスを使ってサーバーを見つけ、リクエストを送信します

このプロセス全体は通常数十ミリ秒しかかかりません。ユーザーはまったく感知しません。

5.3 DNS の設定方法

DNS の設定は通常、2つの場所で行えます：

方法1：ドメイン購入先で設定

ドメインをどこで買ったかに関わらず、そこで DNS レコードを設定します。最も一般的なレコードタイプは A レコード です：

レコードタイプ：A
ホストレコード：通常 @（ドメイン自体を表す、例：my-awesome-website.com）または www（www.my-awesome-website.com を表す）
レコード値：サーバーの IP アドレス、例：123.45.67.89

方法2：サードパーティ DNS サービスの使用

多くのプロフェッショナルは、ドメインレジストラの DNS を使わず、Cloudflare、Alibaba Cloud DNSPod、Tencent Cloud DNS などの専門的な DNS プロバイダーを使用します。これらのサービスは通常より安定しており、解決速度が速く、CDN や DDoS 防御などの付加機能も付いています。

5.4 DNS の反映にはどのくらいかかるか？

多くの人が気になる質問です。答えは：一定ではありません。通常数分から24時間。

DNS を変更すると、世界中のすべての DNS サーバーがこの変更を同期する必要があります。海に石を投げると、波が遠くに届くまで時間がかかるのと同じです。一部の DNS サーバーは更新が速く、数分で反映されます。他のものは遅く、長く待つ必要があるかもしれません。

次のコマンドで DNS が反映されたかを確認できます：

bash

# Windows
ping your-domain.com

# Mac/Linux
ping your-domain.com

ping が成功し、サーバーの IP が表示されれば、DNS は反映されています。

6. HTTPS：ウェブサイトに「鍵」を取り付ける

6.1 HTTP と HTTPS の違い

気付いたかもしれませんが、ウェブサイトのアドレスには http:// で始まるものと https:// で始まるものがあります。この「s」は重要で、「Secure（安全）」を意味します。

HTTP（HyperText Transfer Protocol） はウェブページを転送するためのプロトコルです。データを運ぶトラックと考えてください。しかしこのトラックは透明で——中身がすべての人に見えます。HTTP ウェブサイトで入力したパスワードや個人情報は、転送中に途中の誰かに傍受される可能性があります。

HTTPS（HTTP Secure） は、このトラックに密閉されたコンテナと鍵を追加します。送信者と受信者だけが鍵を持っています。途中の人が傍受しても、中身を理解できません。これが暗号化通信です。

HTTP

❌ 明文传输

 HTTPS 
 ✅ 加密传输 

💡 推荐：Let's Encrypt 免费证书

6.2 なぜ HTTPS が必要なのか？

第一の理由：セキュリティ。HTTPS がなければ、ユーザーがウェブサイトで入力したパスワードは平文で転送されます。少し技術がある人なら誰でも傍受できます。今の時代、HTTPS のないウェブサイトを使う人がいるでしょうか？

第二の理由：ブラウザの警告。Chrome や Edge などの最新ブラウザは、HTTPS のないウェブサイトに「保護されていません」という警告を表示します。ユーザーは警告アイコンを見たらすぐに立ち去ります——登録や決済など論外です。

第三の理由：SEO。Google や Baidu などの検索エンジンは、HTTPS のウェブサイトを優先的にインデックスします。SEO の効果が向上します。

6.3 HTTPS 証明書の取得方法

以前は HTTPS 証明書は高価で、毎年数百から数千元かかりました。今は Let's Encrypt という組織があり、完全に無料の SSL/TLS 証明書を提供しています。また、コミュニティにはインストールと更新を自動化するツールが多数あります。

方法1：Certbot を使用（推奨）

Certbot は、Let's Encrypt 証明書を自動的に申請・設定するツールです。非常にシンプルです：

bash

# Certbot をインストール
sudo apt install -y certbot python3-certbot-nginx

# ワンクリックで証明書を申請し Nginx を設定
sudo certbot --nginx -d example.com -d www.example.com

プロセス中にいくつか質問されます（証明書の有効期限リマインダー用のメールアドレスなど）。回答後、証明書は自動的に設定されます。ウェブサイトにアクセスすると、アドレスバーに小さな鍵アイコンが追加されています。

証明書の有効期限は90日ですが、Certbot が自動更新の cron ジョブを設定してくれます。基本的に気にする必要はありません。

方法2：Cloudflare を使用

Cloudflare の DNS サービスを使用している場合、HTTPS 証明書を自分で設定する必要はまったくありません。Cloudflare が自動的にドメインに HTTPS サポートを提供します。90日ごとの更新の問題も解決してくれます。

6.4 HTTPS 設定後に何が変わるか？

HTTPS を設定すると、ユーザーのアクセスが http://example.com から https://example.com に変わります。この変更は一連のセキュリティ保証をもたらします：

暗号化通信：ユーザーとサーバー間のすべての通信が暗号化されます。
身元確認：証明書は「私が本当にこのウェブサイトであること」を証明でき、フィッシングサイトを防止します。
データの完全性：データが改ざんされていないかを検出できます。

7. CI/CD：ロボットに仕事を任せる

7.1 CI/CD とは何か？

CI/CD は2つの言葉の略称です：Continuous Integration（継続的インテグレーション）と Continuous Deployment（継続的デプロイ）。自動的に仕事をしてくれるロボットシステムと考えてください。

CI/CD がない場合、新機能をリリースするたびにプロセスは次のようになります：

パソコンを開き、GitHub にログイン
最新のコードを取得
テストを実行してバグがないか確認
手動でプロジェクトをビルド
サーバーにログイン
最新のコードを取得
依存関係をインストール
プロジェクトをビルド
サービスを再起動

この9つのステップを、リリースのたびに手動で実行する必要があります。面倒でしょう？しかも、テストの実行を忘れたり、サービスの再起動を忘れたりといったミスが起きやすいです。

CI/CD があれば、プロセスは次のようになります：

コードを GitHub にプッシュ
お茶を飲んで待つ 3.（ロボットが上記の9つのステップを自動的に完了）
ウェブサイトが自動的に更新される

1代码推送

→

2自动测试

→

3自动构建

→

4自动部署

手动部署

❌ 容易出错

 CI/CD 
 ✅ 快速可靠 

これが CI/CD の魅力です：コードをプッシュするだけで、あとはすべて自動的に完了します。

7.2 CI/CD のワークフロー

典型的な CI/CD プロセスは次のようになります：

ステップ1：コードのコミット（Push）

新機能の開発が完了しました。コードを GitHub にプッシュします。

ステップ2：CI（継続的インテグレーション）のトリガー

GitHub がコードの変更を検出し、CI システム（GitHub Actions、GitLab CI など）に通知して作業を開始します。

ステップ3：依存関係のインストールとテスト

CI システムは仮想マシンを起動し、その上で：

プロジェクトに必要なすべての依存関係をインストール
テストコードを実行してバグがないことを確認
プロジェクトをビルドして成果物を生成

テストが失敗した場合、CI はメールで通知します。このデプロイは停止されます。問題のあるコードが本番環境にデプロイされることはありません。

ステップ4：CD（継続的デプロイ）の実行

すべてのテストが通過した後、CI システムは：

SSH 経由でサーバーに接続
最新のコードを取得
依存関係をインストール
プロジェクトをビルド
サービスを再起動

プロセス全体は数分しかかからない可能性があります。すべて自動的に完了します。

7.3 GitHub Actions の設定方法

GitHub Actions は GitHub に組み込まれた CI/CD 機能です。追加費用なし（無料枠は個人プロジェクトに十分です）。設定も非常にシンプルです。

プロジェクトのルートディレクトリに .github/workflows/deploy.yml ファイルを作成し、次の設定を記述します：

yaml

name: Deploy to Production

# トリガー条件：main ブランチにコードがプッシュされたとき
on:
  push:
    branches: [main]

# ジョブリスト
jobs:
  # デプロイジョブ
  deploy:
    # 実行するシステム
    runs-on: ubuntu-latest

    # 具体的なステップ
    steps:
      # 1. コードのチェックアウト
      - name: Checkout code
        uses: actions/checkout@v3

      # 2. Node.js 環境のセットアップ
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      # 3. 依存関係のインストールとビルド
      - name: Install and Build
        run: |
          npm ci
          npm run build

      # 4. サーバーにデプロイ
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/my-website
            git pull origin main
            npm install
            npm run build
            pm2 restart all

この設定ファイルは GitHub Actions に次のことを伝えます：

main ブランチに新しいコードがあったときにトリガー
Ubuntu マシンでタスクを実行
まず Node.js 18 をインストール
次に依存関係をインストールし、プロジェクトをビルド
最後に SSH 経由でサーバーに接続し、一連のデプロイコマンドを実行

これを設定した後、git push origin main するたびに、GitHub が自動的にデプロイを開始します。非常に便利です。

8. モニタリングとログ：ウェブサイトの「夜警」

8.1 なぜモニタリングが必要なのか？

ウェブサイトが公開された後、理論的には24時間365日中断なく稼働するはずです。しかし現実はそれほどうまくはいきません。サーバーはダウンする可能性があります。ネットワークが不安定になる可能性があります。コードにバグがある可能性があります。実際の本番環境では、あらゆる予期せぬ事態が発生する可能性があります。

モニタリングがなければ、ユーザーから電話で「ウェブサイトが開けない」と言われるまで待つしかありません。その時点では遅すぎることが多く、ユーザーはすでに離れている可能性があります。

モニタリングがあれば：

問題の早期発見：CPU 使用率が90%に達した？事前にサーバーを追加。
問題の迅速な特定：ウェブサイトが遅い？モニタリングでボトルネックを確認。
現状把握：1日の訪問者数、トラフィックがピークに達する時間帯。

CPU 使用率45%

内存使用率62%

在线用户23

上次备份：

2024-01-15 14:30

8.2 モニタリングすべき指標

最も重要なモニタリング指標は次の通りです：

指標	正常範囲	超過時の対応
CPU 使用率	< 70%	サーバーのアップグレードまたはコードの最適化
メモリ使用率	< 80%	メモリリークの確認
ディスク使用率	< 80%	ログや不要なファイルの清理
ウェブサイトの到達性	100%	サービスが正常に実行されているか確認
応答時間	< 2秒	データベースクエリの最適化またはキャッシュの追加
エラー率	< 1%	エラーログを確認して問題を特定

8.3 モニタリングの設定方法

最もシンプルなソリューション：Uptime Robot

uptimerobot.com に登録します。ウェブサイトの URL を追加します。5分ごとに自動的にウェブサイトが正常かどうかをチェックします。サイトがダウンするとメール通知を送ります。無料版では50のウェブサイトをモニタリングできます——個人プロジェクトには十分すぎるほどです。

中級ソリューション：Alibaba Cloud/Tencent Cloud モニタリング

サーバーが Alibaba Cloud や Tencent Cloud にある場合、組み込みのモニタリング機能があります。閾値アラートを設定するだけです。

プロフェッショナルソリューション：Prometheus + Grafana

この2つはモニタリング分野の「スイスアーミーナイフ」です。非常に強力で、思いつく限りの指標をモニタリングでき、美しい視覚化ダッシュボードを作成できます。ただし設定は比較的複雑で、経験のある開発者に適しています。

8.4 ログ：問題をどのように調査するか？

モニタリングは「ウェブサイトに問題がある」ことを教えてくれます。しかし、具体的に何が問題で、なぜ問題が起きたのかを知るにはログが必要です。

ログはプログラムの「日記」です。プログラムの実行中に起こったすべてを記録します：

どのユーザーがいつどのページにアクセスしたか
データベースクエリにどのくらい時間がかかったか
エラーがあったかどうか、エラーメッセージは何か

基本的なログの使用方法

サーバーでアプリケーションログを表示：

bash

# PM2 のログを表示
pm2 logs

# Nginx のアクセスログを表示
tail -f /var/log/nginx/access.log

# Nginx のエラーログを表示
tail -f /var/log/nginx/error.log

高度なログソリューション

より複雑なプロジェクトの場合、専門的なログ収集ツールをお勧めします：

Loki：無料のオープンソース。Prometheus と同じチームの製品。
ELK（Elasticsearch + Logstash + Kibana）：強力だが設定が複雑。
Sentry：アプリケーションエラーの収集に特化したツール。エラー情報を自動収集。

8.5 アラート：問題を即座に知るには？

モニタリングは問題があることを教えてくれます。しかし、モニタリングダッシュボードを見続けていない場合はどうすればよいでしょうか？ここでアラートが必要になります。

アラートは、モニタリングシステムが異常を検出したときに、SMS、WeChat、DingTalk、メールなどを通じて自動的に通知します。異なるアラートレベルを設定できます：

緊急（ウェブサイトが完全にダウン）：SMS + 電話。即座に知る必要がある。
重大（エラー率が急上昇）：DingTalk/WeChat メッセージ。見たら対応。
通常（CPU がやや高い）：メールサマリー。1日に1回確認するだけでよい。

アラート設定の核心原則は：段階的なアラート、自分を悩ませない。些細なことすべてに SMS が送られてくるなら、すぐにアラートをオフにしてしまうでしょう。

9. よくある問題のクイックリファレンス

問題の現象	考えられる原因	解決方法
ウェブサイトが開けない	ドメインが未解決 / サーバーダウン / Nginx が未起動	`ping ドメイン` で接続確認；`pm2 list` でサービス状態確認；`systemctl status nginx` で Nginx 確認
空白ページが表示される	ビルド成果物のパスが正しくない / 静的ファイルが正しく設定されていない	Nginx の root パスが dist ディレクトリを指しているか確認
404 ページが見つからない	ルーティングが正しく設定されていない / パスの入力ミス	Nginx 設定に `try_files $uri $uri/ /index.html` を追加
502 Bad Gateway	バックエンドサービスがダウン / ポートが開いていない	`pm2 list` でプロセスが実行中か確認；ポートが正しいか検証
403 Forbidden	権限が正しくない / インデックスディレクトリが有効になっていない	ファイル権限を確認 `chmod -R 755`；Nginx 設定に `autoindex on` を追加
HTTPS 証明書の期限切れ	証明書が更新されていない	`certbot renew` で手動更新；自動更新の cron ジョブを確認
更新後に変更が見えない	ブラウザのキャッシュ / CDN のキャッシュ	Ctrl+Shift+R で強制リフレッシュ；CDN コンソールで「キャッシュをパージ」
ウェブサイトの読み込みが遅い	帯域不足 / キャッシュなし / CDN なし	サーバーの帯域をアップグレード；Redis キャッシュを設定；CDN を導入
データベースに接続できない	データベースが未起動 / パスワード間違い / 権限の問題	データベースサービスの状態を確認；設定の接続情報を検証

まとめ

サービスの公開は体系的なエンジニアリングです。コードのビルドからサーバーのデプロイ、ネットワークの設定からセキュリティの保護、モニタリングとアラートからログ分析まで、あらゆる側面が含まれます。初心者は、最初から完璧を追求する必要はありません。まず最小限の実行可能バージョン（MVP）を動かし、その基盤の上で段階的に改善していきましょう。

プロセス全体の重要ポイントは次のようにまとめられます：

コアプロセス

ビルド → npm run build でコードをブラウザが理解できる HTML/CSS/JS に変換
デプロイ → ビルド成果物をサーバーにアップロード。Nginx リバースプロキシを設定。
ドメイン → ドメインを購入し、DNS 解決をサーバーの IP に設定
HTTPS → Let's Encrypt で無料証明書を申請。データ通信のセキュリティを保護。
CI/CD → 自動デプロイを設定。プッシュ後に自動的に公開。
モニタリング → モニタリングとアラートを設定。問題があれば即座に把握。

学習パスの提案

1日目：Vercel/Netlify で静的ウェブページをデプロイ。「コードがウェブサイトになる」体験をする。
1週間目：クラウドサーバーをレンタル。Node.js プロジェクトを手動でデプロイ。ドメインと HTTPS を設定。
2〜4週間目：完全な CI/CD パイプラインを設定。モニタリングとアラートシステムを構築。
継続的学習：Docker コンテナ化、Kubernetes クラスタ、マイクロサービスアーキテクチャを学ぶ。

用語集

用語	英語	わかりやすい説明
ビルド	Build	ソースコードを翻訳・パッケージ化してブラウザが実行できる形式にする
デプロイ	Deploy	コードをサーバーに置いてユーザーがアクセスできるようにする
サーバー	Server	24時間365日稼働し、インターネットに接続されたコンピュータ
ドメイン	Domain	ウェブサイトの覚えやすい名前（例：baidu.com）
DNS	Domain Name System	ドメイン名を IP アドレスに変換する「電話帳」
HTTP	HyperText Transfer Protocol	ウェブページ転送プロトコル（安全でない、平文通信）
HTTPS	HTTP Secure	暗号化されたウェブページ転送プロトコル（安全）
Nginx	Engine X	高性能なウェブサーバー。リバースプロキシとして使用。
リバースプロキシ	Reverse Proxy	入り口に立つ案内人。リクエストをバックエンドに転送する。
SSH	Secure Shell	サーバーにリモートログインする暗号化ツール
CDN	Content Delivery Network	世界中に分散されたサーバーネットワーク。アクセスを高速化。
CI/CD	Continuous Integration/Deployment	自動化パイプライン。プッシュ後に自動的にテスト・デプロイ。
SSL/TLS	Secure Sockets Layer / Transport Layer Security	暗号化プロトコル。HTTPS のセキュリティを提供。
PM2	Process Manager 2	Node.js プロセスマネージャー。アプリケーションの継続実行を管理。

CI/CD 自動化 ​

1. なぜ「サービスを公開」する必要があるのか？ ​

2. ビルド：コードを「持ち運び可能なパッケージ」に変える ​

2.1 なぜビルドが必要なのか？ ​

2.2 ビルドは具体的に何をするのか？ ​

2.3 ビルドの実行方法 ​

2.4 ビルド成果物には何が含まれているか？ ​

3. サーバー：決して閉まらない「家」を見つける ​

3.1 サーバーとは何か？ ​

3.2 サーバーの選び方 ​

3.4 主要クラウドプロバイダーの比較 ​

3.5 サーバーを取得した後は何をすべきか？ ​

4. デプロイ：コードを「家」に搬入する ​

4.1 デプロイとは何か？ ​

4.2 コードをサーバーにアップロードする方法 ​

4.3 デプロイの具体的なステップ ​

5. ドメインと DNS：ウェブサイトに良い名前を付ける ​

5.1 なぜドメインを買う必要があるのか？ ​

5.2 DNS とは何か？ ​

5.3 DNS の設定方法 ​

5.4 DNS の反映にはどのくらいかかるか？ ​

6. HTTPS：ウェブサイトに「鍵」を取り付ける ​

6.1 HTTP と HTTPS の違い ​

6.2 なぜ HTTPS が必要なのか？ ​

6.3 HTTPS 証明書の取得方法 ​

6.4 HTTPS 設定後に何が変わるか？ ​

7. CI/CD：ロボットに仕事を任せる ​

7.1 CI/CD とは何か？ ​

7.2 CI/CD のワークフロー ​

7.3 GitHub Actions の設定方法 ​

8. モニタリングとログ：ウェブサイトの「夜警」 ​

8.1 なぜモニタリングが必要なのか？ ​

8.2 モニタリングすべき指標 ​

8.3 モニタリングの設定方法 ​

8.4 ログ：問題をどのように調査するか？ ​

8.5 アラート：問題を即座に知るには？ ​

9. よくある問題のクイックリファレンス ​

まとめ ​

コアプロセス ​

学習パスの提案 ​

用語集 ​

CI/CD 自動化

1. なぜ「サービスを公開」する必要があるのか？

2. ビルド：コードを「持ち運び可能なパッケージ」に変える

2.1 なぜビルドが必要なのか？

2.2 ビルドは具体的に何をするのか？

2.3 ビルドの実行方法

2.4 ビルド成果物には何が含まれているか？

3. サーバー：決して閉まらない「家」を見つける

3.1 サーバーとは何か？

3.2 サーバーの選び方

3.4 主要クラウドプロバイダーの比較

3.5 サーバーを取得した後は何をすべきか？

4. デプロイ：コードを「家」に搬入する

4.1 デプロイとは何か？

4.2 コードをサーバーにアップロードする方法

4.3 デプロイの具体的なステップ

5. ドメインと DNS：ウェブサイトに良い名前を付ける

5.1 なぜドメインを買う必要があるのか？

5.2 DNS とは何か？

5.3 DNS の設定方法

5.4 DNS の反映にはどのくらいかかるか？

6. HTTPS：ウェブサイトに「鍵」を取り付ける

6.1 HTTP と HTTPS の違い

6.2 なぜ HTTPS が必要なのか？

6.3 HTTPS 証明書の取得方法

6.4 HTTPS 設定後に何が変わるか？

7. CI/CD：ロボットに仕事を任せる

7.1 CI/CD とは何か？

7.2 CI/CD のワークフロー

7.3 GitHub Actions の設定方法

8. モニタリングとログ：ウェブサイトの「夜警」

8.1 なぜモニタリングが必要なのか？

8.2 モニタリングすべき指標

8.3 モニタリングの設定方法

8.4 ログ：問題をどのように調査するか？

8.5 アラート：問題を即座に知るには？

9. よくある問題のクイックリファレンス

まとめ

コアプロセス

学習パスの提案

用語集