アプリのデプロイ

開発後

プロジェクトのライフサイクルのこのセクションでは、解決すべき広範囲の問題が潜在的に存在します。 したがって、手動介入をできるだけ少なくする方法でこれらの問題を処理するツールチェーンを作成することが重要です。

この特定のプロジェクトに関して考慮すべき点がいくつかあります。

• 実稼働ビルドの生成: ファイルが最小化され、チャンク化され、ツリーシェイクが適用され、バージョンが「キャッシュが無効化」されていることを確認します。
• テストの実行: テストの範囲は、「このコードは適切にフォーマットされていますか?」などです。「これは期待どおりの動作をするか?」ということを確認し、テストが失敗することを確認すると展開が妨げられます。
• 更新されたコードを実際にライブデプロイした URL: または、最初に確認できるようにステージング URL にデプロイすることもできます。

メモ： キャッシュ無効化は、このモジュールではこれまでに見たことのない新しい用語です。これはブラウザー自体のキャッシュメカニズムを破壊する戦略であり、ブラウザーにコードの新しいコピーを強制的にダウンロードさせます。 Vite （そして実際には他の多くのツール）は、新しいビルドごとに一意のファイル名を生成します。この一意のファイル名はブラウザーのキャッシュを「破棄」し、デプロイされたコードが更新されるたびにブラウザーが新しいコードをダウンロードするようにします。

上記のタスクはさらに別のタスクに分割されます。ほとんどのウェブ開発チームは、開発後のフェーズの少なくとも一部について独自の条件とプロセスを持っていることに注意してください。

このプロジェクトでは、 GitHub Pages の素晴らしい静的ホスティングサービスを使用してプロジェクトをホストします。これは、インターネット上でウェブサイトを提供しているだけでなく、ウェブサイトへの URL も与えてくれます。これは素晴らしいことです。MDN の例示用ウェブサイトの多くは GitHub Pages でホストされています。

ホスティングへのデプロイはプロジェクトのライフサイクルの最後になる傾向がありますが、 GitHub Pages などのサービスを使用すると、デプロイのコスト(金銭面と実際のデプロイに必要な時間の両方)が削減され、開発中にデプロイすることが可能になります。進行中の作業を共有するか、他の目的でプレリリースするかのいずれかです。

GitHub は、新しいコードを実際のウェブサイトに変換するためのスムーズなワークフローを提供しています。

• コードを GitHub にプッシュします。
• メインブランチに新しいプッシュがあったときに発生する GitHub Action を定義し、コードをビルドして特定の場所に配置します。
• GitHub Pages は、そのコードを特定の URL で提供します。

独自のビルドツールチェーンを決定する際に探すことをお勧めするのは、まさにこの種の接続されたサービスです。コードをコミットして GitHub にプッシュすると、更新されたコードによってビルドルーチン全体が自動的にトリガーされます。すべて問題がなければ、ライブ変更が自動的にデプロイされます。実行する必要があるアクションは、最初の「プッシュ」だけです。

ただし、これらの手順を設定する必要があるので、それについてはこれから見ていきます。

ビルドプロセス

繰り返しになりますが、開発には Vite を使用しているため、ビルドオプションの追加は非常に簡単です。前述のように、開発や検査の目的で実行するだけでなく、Vite が本番用にすべての準備を行う独自の npm run build スクリプトがすでに指定されています。これには、コードのミニフィケーションおよびツリーシェイク、ファイル名のキャッシュ破棄が含まれます。

プロジェクトでは常に build スクリプトを定義しておくことがベストプラクティスです。そうすることで、それぞれのプロジェクトに固有のビルドコマンドの引数を覚えておく必要がなく、npm run build を実行するだけで、常に完全なビルド段階を実行することができます。

新しく作成された実稼働コードは、 dist という新しいディレクトリーに配置されます。このディレクトリーには、ウェブサイトを実行するために必要なすべてのファイルが含まれており、すぐにサーバーにアップロードできます。

ただし、このステップを手動で実行することが最終的な目的ではありません。私たちが望んでいるのは、ビルドが自動的に行われ、 dist ディレクトリーの結果がウェブサイトにライブでデプロイされることです。

GitHub への変更のコミット

このセクションでは、コードを git リポジトリーに保存するまでの手順を説明しますが、これは git チュートリアルとは程遠いものです。優れたチュートリアルや書籍が数多く提供されており、 Git and GitHub ページから始めるのが適しています。

先ほど作業ディレクトリーを git 作業ディレクトリーとして初期化しました。これを簡単に確認するには、次のコマンドを実行します。

git status

どのファイルが追跡されているか、どのファイルがステージングされているかなどのステータスレポートを取得する必要があります。これらの用語はすべて git 文法の一部です。 fatal: not a git repository というエラーが返された場合、作業ディレクトリーは git 作業ディレクトリーではないため、 git init を使用して git を初期化する必要があります。

今、私たちの前には 3 つのタスクがあります。

• ステージに加えた変更を追加します( git がファイルをコミットする場所の特別な名前)。
• 変更をリポジトリーにコミットします。
• 変更を GitHub にプッシュします。

1. 変更を追加するには、次のコマンドを実行します。

   bash

   git add .
   

   最後のピリオドに注意してください。これは「このディレクトリー内のすべて」を意味します。 git add . コマンドは、少し強力なアプローチです。これまでに行ったすべてのローカル変更を一度に追加します。追加するものをより細かく制御したい場合は、対話型プロセスに git add -p を使用するか、 git add path/to/file を使用して個々のファイルを追加します。

2. これですべてのコードがステージングされ、コミットできるようになりました。 次のコマンドを実行します。

   bash

   git commit -m 'committing initial code'
   

   メモ: コミットメッセージには自由に何を書き込んでも構いませんが、適切なコミットメッセージに関する役立つヒントがウェブ上にいくつかあります。変更の内容を明確に説明できるように、短く簡潔に説明するようにしてください。

3. 最後にコードを GitHub でホストされているリポジトリーにプッシュする必要があります。今すぐそうしましょう。

   GitHub で https://github.com/new にアクセスし、このコードをホストする独自のリポジトリーを作成します。

4. リポジトリーにスペースを含まない短くて覚えやすい名前 (単語を区切るにはハイフンを使用します) と説明を付けて、ページの下部にある Create repository をクリックします。

   これで、新しい GitHub リポジトリーを指す「リモート」 URL が作成されたはずです。

   

5. このリモートロケーションは、そこにプッシュする前に、ローカル git リポジトリーに追加する必要があります。そうしないと、そのロケーションを見つけることができません。次の構造を持つコマンドを実行する必要があります (ここでは、特に GitHub を初めて使用する場合は、SSH オプションではなく、指定された HTTPS オプションを使用してください)。

   bash

   git remote add origin https://github.com/your-name/repo-name.git
   

   したがって、上のスクリーンショットのように、「リモート」 URL が https://github.com/remy/super-website.git の場合、コマンドは次のようになります。

   bash

   git remote add origin https://github.com/remy/super-website.git
   

   URL を独自のリポジトリーに変更し、今すぐ実行します。

   メモ: リポジトリーの名前を選んだ後、前章で述べたように、vite.config.js の base オプションがこの名前を反映していることを確認してください。そうしないと、JavaScript および CSS 資産が正しくリンクされません。

6. これで、コードを GitHub にプッシュする準備が整いました。今すぐ次のコマンドを実行します。

   bash

   git push origin main
   

   この時点で、 Git がプッシュの送信を許可する前に、ユーザー名とパスワードの入力を求められます。これは、前のスクリーンショットに見られるように、 SSH オプションではなく HTTPS オプションを使用したためです。このためには、 GitHub ユーザー名が必要です。次に、 2 要素認証 (2FA) が有効になっていない場合は、 GitHub パスワードが必要です。可能であれば 2FA を使用することを常にお勧めしますが、その場合は「個人アクセストークン」も使用する必要があることに注意してください。 GitHub のヘルプページには、その入手方法を説明する優れた簡単なチュートリアルが記載されています。

この最後のコマンドは、git に、ブランチ main を使用して、origin と名付けた「リモート」の場所にコードをプッシュするように指示します (これは github.com でホストされているリポジトリーです。好きな名前に名付けることもできます)。これまでブランチについてはまったく触れていませんが、 "main" ブランチは、私たちの作業のための既定の場所であり、git が起動する場所でもあります。ウェブサイトを構築するためにトリガーされる措置を定義するとき、その措置が "main" ブランチの変更を監視するようにします。

プロジェクトを Git でコミットし、GitHub リポジトリーにプッシュしたら、ツールチェーンの次のステップは、プロジェクトをライブでウェブ上にデプロイできるようにすることです。

デプロイに GitHub Actions を使用する

GitHub Actions は、ESLint の設定と同様に、掘り下げるべき深い分野です。最初の試みで適切な設定を行うことは容易ではありませんが、「静的ウェブサイトを構築し、 GitHub Pages に展開」といった一般的な課題については、コピーして貼り付けることができる例がたくさんあります。独自の GitHub Actions ワークフローによる公開の手順に従ってください。動作例については、 GitHub Action ファイル を調べるとよいでしょう。(ファイル名は任意です。)

このファイルをメインブランチにコミットした後、コミットタイトルの横に小さな緑色のチェックマークが表示されます。

黄色のドットが表示されている場合は、そのアクションが実行中であることを意味し、赤い十字が表示されている場合は、そのアクションが失敗したことを意味します。アイコンをクリックすると、ご自身で実行したビルド作業（この例では "Deploy build" という名前付き）のステータスとログを確認できます。

さらに数分待った後、 GitHub Pages の URL にアクセスして、自分のウェブサイトがウェブ上で公開されていることを確認できます。リンクは https://<your-name>.github.io/<repo-name> のようになります。この例では、 https://mdn.github.io/client-toolchain-example/ です。

これで、ツールチェーンの最後のリンク、コードが動作することを確認するテストに移ります。

テスト

テスト自体は、フロントエンド開発の領域内であっても、広大なテーマです。プロジェクトに初期テストを追加する方法と、そのテストを使用してプロジェクトのデプロイメントの発生を防止または許可する方法を説明します。

テストに近づくとき、問題に対処する方法はたくさんあります。

• エンドツーエンドのテスト。訪問者が何かをクリックすると、別のことが起こります。
• 統合テスト。基本的には、「あるコードブロックが別のブロックに接続されても機能するかどうか」をテストします。
• ユニットテスト。機能の小さな特定のビットをテストして、期待どおりに動作するかどうかを確認します。
• その他にも多くの種類テストがあります。また多数の有用なテスト情報については、クロスブラウザーテストモジュールを参照してください。

また、テストは JavaScript に限定されないことにも注意してください。テストはレンダリングされた DOM 、ユーザーインタラクション、 CSS 、さらにはページの外観に対して実行できます。

しかし、このプロジェクトでは、 GitHub API データが正しい書式化されているかどうかを調べる小さな検査を作成します。そうでない場合、検査は失敗し、プロジェクトは公開されません。それ以上のことは、このモジュールの範囲を超えます。検査は実に巨大なテーマであり、それ自体で別個のモジュールを必要とします。この章では、少なくともテストの必要性を認識し、さらに詳しく学びたいと思うきっかけとなるような選択されていることを期待しています。

大切なのはテストそのものではありません。重要なのは、独自のビルドアクションをすでに記述しているので、テストを実行する段階をビルドの前に追加することができます。テストが失敗すると、ビルドは失敗し、デプロイは現れません。

良いニュースは、Vite を使用しているため、Vite にはすでにテスト用の優れた統合ツール、Vitest が用意されていることです。

始めましょう。

1. Vitest をインストールします。

   bash

   npm install --save-dev vitest
   

2. package.json で scripts メンバーを探し、次のテストおよびビルドコマンドが含まれるように更新します。

   json

   "scripts": {
     // …
     "test": "vitest"
   }
   

   メモ: Vitest と Vite を一緒に使用することの利点は、他のテストフレームワークを使用する場合、テストファイルの変換方法を記述した別の設定を追加する必要がありますが、Vitest は Vite の設定を自動的に使用します。

3. これで、コードベースにテストを追加する必要があります。通常、App.jsx というファイルの機能をテストする場合、その隣に App.test.jsx というファイルを追加します。この例では、データをテストするだけなので、テストを保存するための別のディレクトリーを作成しましょう。前回の章でダウンロードしたサンプルリポジトリーを開き、tests フォルダーをコピーしてください。

4. これで手動でテストを実行できます。コマンドラインから、次のように実行します。

   bash

   npm run test
   

   次のような出力が表示されます。

   > client-toolchain-example@1.0.0 test
   > vitest
   
   
   DEV  v1.6.0 /Users/joshcena/Desktop/work/Tech/projects/mdn/client-toolchain-example
   
   ✓ tests/api.test.js (1) 896ms
     ✓ GitHub API returns the right response 896ms
   
   Test Files  1 passed (1)
        Tests  1 passed (1)
     Start at  23:12:25
     Duration  1.03s (transform 15ms, setup 0ms, collect 5ms, tests 896ms, environment 0ms, prepare 38ms)
   
   
   PASS  Waiting for file changes...
         press h to show help, press q to quit
   

   これは、テストに合格したことを意味します。 Vite と同様、ファイルが保存されると変更を監視し、検査を再実行します。 q を押すと終了できます。

5. テストをビルドアクションに配線して、テストが失敗した場合にビルドをブロックする必要があります。 .github/workflows/github-pages.yml ファイル（またはビルドアクションに付けたファイル名）を開き、 npm run build を実行するステップの直前に、次のステップを追加します。

   yaml

   - name: Install deps
     run: npm ci
   
   # Add this
   - name: Run tests
     run: npm run test
   
   - name: Build
     run: npm run build
   

   これにより、ビルド段階の前にテストが実行されます。テストに失敗した場合、ビルドは失敗となり、デプロイは現れません。

6. 以前に使用したものと同様のコマンドを使用して、新しいコードを GitHub にアップロードする必要があります。

   bash

   git add .
   git commit -m 'adding test'
   git push origin main
   

   場合によっては、ビルドされたコードの結果をテストしたい場合があります（これは、私たちが作成したオリジナルのコードとは異なるため）。そのため、ビルドコマンドの後にテストを実行する必要があるかもしれません。独自のプロジェクトに取り組んでいるときは、これらすべての個別の側面を考慮する必要があります。

最後に、プッシュしてから 1 分ほど後、GitHub Pages がプロジェクトの更新を展開します。ただし、導入したテストに合格した場合に限ります。

まとめ

サンプルケーススタディとモジュールはこれで終わりです。お役に立てば幸いです。自分をクライアント側ツールのウィザードとみなすまでには長い道のりがありますが、このモジュールが、クライアント側のツールを理解するための重要な第一歩となり、さらに学んで新しいツールを試す自信を与えてくれることを願っています。

ツールチェーンのすべての部分を要約してみましょう。

• コードの品質と保守は、 ESLint と Prettier によって実施されます。これらのツールは、npm install --dev eslint prettier eslint-plugin-react ... によって、devDependencies として自分のプロジェクトに追加されます（この具体的なプロジェクトでは React を使用しているため、ESLint プラグインが必要です）。
• コード品質ツールが読み取る構成ファイルが 2 つあります。 eslint.config.js と .prettierrc です。
• 開発中は、npm を使用して依存関係を追加し続けます。Vite 開発サーバーはバックグラウンドで実行され、変更を監視し、ソースを自動的にビルドします。
• デプロイは、GitHub （"main" ブランチ）に変更をプッシュすることで処理されます。これにより、GitHub Actions によるビルドと展開が開始され、プロジェクトが公開されます。この例では、 URL は https://mdn.github.io/client-toolchain-example/ ですが、皆様は自分の固有の URL になるでしょう。
• また、GitHub API フィードから正しいデータ形式のデータが渡されなかった場合に、サイトのビルドと展開をブロックする単純な検査も実施しています。

挑戦したい方は、このツールチェーンの一部を最適化できるかどうか考えてみてください。自問すべき質問は以下の通りです。

• 必要な plotly.js の機能だけを取り出すことはできますか？そうすることで、JavaScript バンドルのサイズを縮小することができます。
• 型チェック用の TypeScript や CSS リンティング用の stylelint、その他のツールを追加したくなるかもしれません。
• React を もっと小さいもの に置き換えることはできますか?
• パフォーマンス監査など、不正なビルドのデプロイを防ぐためのテストをさらに追加していただけますか?
• 新しいデプロイが成功したか失敗したかを知らせる通知を設定していただけますか?

• 前のページ
• Overview: クライアントサイドウェブ開発ツールを理解する