本文へスキップ
バージョン: 3.5.2

デプロイメント

本番環境用のウェブサイトの静的ファイルをビルドするには、以下のコマンドを実行します。

npm run build

完了すると、静的ファイルがbuildディレクトリに生成されます。

注記

Docusaurusの役割は、サイトをビルドし、buildディレクトリに静的ファイルを生成することだけです。

これらの静的ファイルをどのようにホストするかは、ユーザーの責任となります。

Vercel、GitHub Pages、Netlify、Render、Surgeなどの静的サイトホスティングサービスにサイトをデプロイできます。

Docusaurusサイトは静的にレンダリングされるため、一般的にJavaScriptなしでも動作します！

設定​

ルーティングを最適化し、正しい場所からファイルを提供するには、docusaurus.config.jsで以下のパラメーターが必要です。

名前説明
urlサイトのURL。https://my-org.com/my-project/にデプロイされたサイトの場合、urlはhttps://my-org.com/です。
baseUrlプロジェクトのベースURL（末尾にスラッシュが必要）。https://my-org.com/my-project/にデプロイされたサイトの場合、baseUrlは/my-project/です。

ローカルでのビルドテスト​

本番環境にデプロイする前に、ローカルでビルドをテストすることが重要です。Docusaurusは、そのためのdocusaurus serveコマンドを提供しています。

npm run serve

デフォルトでは、サイトはhttp://localhost:3000/でロードされます。

末尾のスラッシュの設定​

Docusaurusには、URL/リンクと出力されるファイル名のパターンをカスタマイズできるtrailingSlash設定があります。

デフォルト値は通常問題ありません。しかし、各静的ホスティングプロバイダーは**異なる動作**を示し、まったく同じサイトをさまざまなホストにデプロイすると、異なる結果になる可能性があります。ホストによっては、この設定を変更することが役立つ場合があります。

ヒント

ホストの動作を理解し、trailingSlashを適切に設定するには、slorber/trailing-slash-guideを参照してください。

環境変数の使用​

機密性の高い情報を環境変数に格納することは一般的です。しかし、通常のDocusaurusウェブサイトでは、docusaurus.config.jsファイルがNode.js環境への唯一のインターフェースであり（アーキテクチャの概要を参照）、それ以外のもの（MDXページ、Reactコンポーネントなど）はクライアントサイドであり、processグローバル変数に直接アクセスできません。この場合、customFieldsを使用して、環境変数をクライアントサイドに渡すことができます。

docusaurus.config.js
// If you are using dotenv (https://www.npmjs.com/package/dotenv)
import 'dotenv/config';

export default {
  title: '...',
  url: process.env.URL, // You can use environment variables to control site specifics as well
  customFields: {
    // Put your custom environment here
    teamEmail: process.env.EMAIL,
  },
};
home.jsx
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';

export default function Home() {
  const {
    siteConfig: {customFields},
  } = useDocusaurusContext();
  return <div>Contact us through {customFields.teamEmail}!</div>;
}

ホスティングプロバイダーの選択​

一般的なホスティングオプションをいくつか紹介します。

  • 自己ホスティング（Apache2やNginxなどのHTTPサーバーを使用）。
  • Jamstackプロバイダー（例：NetlifyとVercel）。ここではこれらを参考として使用しますが、同じロジックは他のプロバイダーにも適用できます。
  • GitHub Pages（定義上、これもJamstackですが、ここでは別途比較します）。

どれを選択するか迷ったら、以下の質問を検討してください。

このためにどれだけのリソース（お金、時間など）を投資できますか？

  • 🔴 自己ホスティングには、ネットワーク、Linux、Webサーバー管理の経験が必要です。最も難しいオプションであり、成功させるためには最も多くの時間が必要です。費用面では、クラウドサービスはほとんど無料ではなく、オンプレミスサーバーの購入/デプロイはさらに高額になる可能性があります。
  • 🟢 Jamstackプロバイダーは、ほぼ瞬時に動作するウェブサイトを設定でき、簡単に構成できるサーバーサイドリダイレクトなどの機能を提供します。多くのプロバイダーは、無料プランでもほとんど到達しないような寛大なビルド時間クォータを提供しています。ただし、無料プランには制限があり、その制限に達したら支払う必要があります。詳細については、プロバイダーの価格表を確認してください。
  • 🟡 GitHub Pagesのデプロイワークフローは、設定が面倒です。（証拠：GitHub Pagesへのデプロイの長さをご覧ください！）ただし、このサービス（ビルドとデプロイを含む）は、パブリックリポジトリでは常に無料であり、動作させるための詳細な手順を用意しています。
どの程度のサーバーサイドのカスタマイズが必要ですか？
  • 🟢 自己ホスティングでは、サーバー全体の構成にアクセスできます。リクエストURLに基づいて異なるコンテンツを提供するように仮想ホストを設定したり、複雑なサーバーサイドリダイレクトを実行したり、認証を実装したりすることができます。多くのサーバーサイド機能が必要な場合は、ウェブサイトを自己ホストしてください。
  • 🟡 Jamstackは通常、いくつかのサーバーサイド設定（例：URLフォーマット（末尾のスラッシュ）、サーバーサイドリダイレクトなど）を提供します。
  • 🔴 GitHub Pagesは、HTTPSの適用とCNAMEレコードの設定以外、サーバーサイドの設定を公開していません。
共同作業に適したデプロイワークフローが必要ですか？
  • 🟡 自己ホスト型サービスはNetlifyなどの継続的デプロイ機能を利用できますが、より多くの作業が必要です。通常、特定の担当者をデプロイ管理に割り当て、他の2つのオプションとは異なり、ワークフローはそれほどgitベースではありません。
  • 🟢 NetlifyとVercelは、プルリクエストごとにデプロイプレビューを提供しており、チームが本番環境にマージする前に作業を確認するのに役立ちます。また、デプロイへのアクセス権限が異なるメンバーでチームを管理することもできます。
  • 🟡 GitHub Pagesは、複雑でない方法ではデプロイプレビューを実行できません。1つのリポジトリは、1つのサイトデプロイメントのみに関連付けることができます。一方、サイトのデプロイへの書き込みアクセス権を持つユーザーを制御できます。

万能な解決策はありません。選択を行う前に、ニーズとリソースを比較検討する必要があります。

自己ホスティング​

Docusaurusは、docusaurus serveを使用して自己ホストできます。--portと--hostを使用してポートとホストを変更します。

npm run serve -- --build --port 80 --host 0.0.0.0
警告

静的ホスティングプロバイダー/CDNと比較して、最適なオプションではありません。

警告

以降のセクションでは、いくつかの一般的なホスティングプロバイダーと、Docusaurusサイトを最も効率的にデプロイするための設定方法を紹介します。Docusaurusはこれらのサービスと提携しておらず、この情報は便宜上提供されているものです。一部の記述はサードパーティによって提供されており、最新のAPIの変更が反映されていない場合があります。古いコンテンツを見つけた場合は、PRを送信していただけます。

ベストエフォートベースでのみコンテンツを提供できるため、新しいホスティングオプションを追加するPRの受付を停止しました。ただし、独自のサイト（ブログやプロバイダーの公式ウェブサイトなど）に記述を公開し、リンクの追加を依頼することは可能です。

Netlifyへのデプロイ​

DocusaurusサイトをNetlifyにデプロイするには、まず以下のオプションが正しく設定されていることを確認してください。

docusaurus.config.js
export default {
  url: 'https://docusaurus-2.netlify.app', // Url to your site with no trailing slash
  baseUrl: '/', // Base directory of your site relative to your repo
  // ...
};

次に、Netlifyでサイトを作成します。

サイトを設定する際に、ビルドコマンドとディレクトリを次のように指定します。

  • ビルドコマンド: npm run build
  • 公開ディレクトリ: build

これらのビルドオプションを設定しなかった場合でも、サイト作成後に「サイト設定」->「ビルドとデプロイ」に移動できます。

上記のオプションで適切に設定されると、サイトはデプロイされ、デプロイブランチ（デフォルトはmain）にマージされると自動的に再デプロイされます。

警告

一部のDocusaurusサイトでは、docsフォルダがwebsiteフォルダの外側に配置されています（おそらく以前のDocusaurus v1サイト）。

repo           # git root
├── docs       # MD files
└── website    # Docusaurus root

websiteフォルダをNetlifyのベースディレクトリとして使用する場合、docsフォルダを更新してもNetlifyはビルドをトリガーしません。この場合は、カスタムignoreコマンドを設定する必要があります。

website/netlify.toml
[build]
  ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../docs/"
警告

デフォルトで、NetlifyはDocusaurusのURLに末尾のスラッシュを追加します。

小文字のURL、不要なリダイレクト、および404エラーを防ぐために、Netlifyの設定「Post Processing > Asset Optimization > Pretty Urls」を無効にすることをお勧めします。

非常に注意してください：「資産の最適化を無効にする」グローバルチェックボックスは壊れており、実際には「Pretty URLs」設定を無効にしません。必ず個別にチェックを外してください。

Netlifyの「Pretty Urls」設定を有効にしたい場合は、trailingSlashのDocusaurus設定を適切に調整してください。

詳細については、slorber/trailing-slash-guideを参照してください。

Vercelへのデプロイ​

DocusaurusプロジェクトをVercelにデプロイすると、パフォーマンスと使いやすさの点でさまざまなメリットが得られます。

VercelのGit統合を使用してDocusaurusプロジェクトをデプロイするには、Gitリポジトリにプッシュされていることを確認してください。

インポートフローを使用して、プロジェクトをVercelにインポートします。インポート時に、関連するすべてのオプションが事前に設定されていますが、これらのオプションを変更することもできます。

プロジェクトがインポートされると、ブランチへの後続のプッシュによってプレビューデプロイメントが生成され、本番ブランチ（通常は「main」または「master」）に加えられたすべての変更は、本番デプロイメントになります。

GitHub Pagesへのデプロイ​

Docusaurusは、すべてのGitHubリポジトリで無料で提供されるGitHub Pagesに簡単に公開する方法を提供します。

概要​

通常、公開プロセスには2つのリポジトリ（少なくとも2つのブランチ）が関与します。ソースファイルを含むブランチと、GitHub Pagesで提供されるビルド出力を含むブランチです。以降のチュートリアルでは、それぞれ「ソース」と「デプロイ」と呼びます。

各GitHubリポジトリには、GitHub Pagesサービスが関連付けられています。デプロイリポジトリがmy-org/my-project（my-orgは組織名またはユーザー名）と呼ばれる場合、デプロイされたサイトはhttps://my-org.github.io/my-project/に表示されます。デプロイリポジトリがmy-org/my-org.github.io（組織GitHub Pagesリポジトリ）と呼ばれる場合、サイトはhttps://my-org.github.io/に表示されます。

情報

GitHub Pagesでカスタムドメインを使用する場合は、staticディレクトリにCNAMEファイルを作成します。staticディレクトリ内のものはすべて、デプロイのためにbuildディレクトリのルートにコピーされます。カスタムドメインを使用する場合は、baseUrl: '/projectName/'からbaseUrl: '/'に戻し、urlをカスタムドメインに設定できます。

詳細については、GitHub Pagesのドキュメントユーザー、組織、およびプロジェクトページを参照してください。

GitHub Pagesは、デプロイ準備完了ファイル（docusaurus buildからの出力）をデフォルトブランチ（master/main、通常）またはgh-pagesブランチから、ルートまたは/docsフォルダから取得します。これはリポジトリの「設定 > Pages」で設定できます。このブランチは「デプロイブランチ」と呼ばれます。

ソースブランチからデプロイブランチへのサイトのデプロイを1つのコマンドで実行できるdocusaurus deployコマンドを提供しています。クローン、ビルド、コミットを行います。

docusaurus.config.jsの設定​

最初に、docusaurus.config.jsを変更し、以下のパラメーターを追加します。

名前説明
organizationNameデプロイリポジトリを所有するGitHubユーザーまたは組織。
projectNameデプロイリポジトリの名前。
deploymentBranchデプロイブランチの名前。組織以外のGitHub Pagesリポジトリ（projectNameが.github.ioで終わらない場合）では、デフォルトで'gh-pages'になります。それ以外の場合は、設定フィールドまたは環境変数として明示的に指定する必要があります。

これらのフィールドには、優先順位が高い対応する環境変数（ORGANIZATION_NAME、PROJECT_NAME、DEPLOYMENT_BRANCH）もあります。

警告

GitHub PagesはデフォルトでDocusaurusのURLに末尾のスラッシュを追加します。trailingSlash設定（trueまたはfalse、undefinedではない）を設定することをお勧めします。

例

docusaurus.config.js
export default {
  // ...
  url: 'https://endiliey.github.io', // Your website URL
  baseUrl: '/',
  projectName: 'endiliey.github.io',
  organizationName: 'endiliey',
  trailingSlash: false,
  // ...
};
警告

デフォルトでは、GitHub Pagesは公開されたファイルをJekyllで処理します。Jekyllは_で始まるファイルをすべて破棄するため、staticディレクトリに.nojekyllという名前の空のファイルを追加してJekyllを無効にすることをお勧めします。

環境設定​

名前説明
USE_SSHGitHubリポジトリへの接続に、デフォルトのHTTPSではなくSSHを使用する場合はtrueに設定します。ソースリポジトリのURLがSSH URL（例：[email protected]:facebook/docusaurus.git）の場合、USE_SSHはtrueと推測されます。
GIT_USERデプロイリポジトリへのプッシュアクセス権を持つGitHubアカウントのユーザー名。自分のリポジトリの場合は、通常はGitHubのユーザー名になります。SSHを使用していない場合に必要で、それ以外の場合は無視されます。
GIT_PASS非対話型デプロイ（例：継続的デプロイ）を容易にするため、gitユーザー（GIT_USERで指定）のパーソナルアクセストークン。
CURRENT_BRANCHソースブランチ。通常、ブランチはmainまたはmasterですが、gh-pages以外の任意のブランチにすることができます。この変数に何も設定されていない場合、docusaurus deployが呼び出された現在のブランチが使用されます。
GIT_USER_NAMEデプロイリポジトリにプッシュする際に使用するgit config user.nameの値。
GIT_USER_EMAILデプロイリポジトリにプッシュする際に使用するgit config user.emailの値。

GitHub Enterpriseインストールはgithub.comと同じように動作します。組織のGitHub Enterpriseホストを環境変数として設定するだけです。

名前説明
GITHUB_HOSTGitHub Enterpriseサイトのドメイン名。
GITHUB_PORTGitHub Enterpriseサイトのポート。

デプロイ​

最後に、GitHub Pagesにサイトをデプロイするには、以下を実行します。

GIT_USER=<GITHUB_USERNAME> yarn deploy
警告

2021年8月以降、GitHubでは、パスワードの代わりにパーソナルアクセストークンを使用するすべてのコマンドラインサインインが必要です。GitHubでパスワードの入力を求められたら、代わりにPATを入力してください。詳細については、GitHubのドキュメントを参照してください。

または、SSH（USE_SSH=true）を使用してログインできます。

GitHub Actionsを使用したデプロイのトリガー​

GitHub Actionsを使用すると、リポジトリ内でソフトウェア開発ワークフローを自動化、カスタマイズ、および実行できます。

以下のワークフローの例では、ウェブサイトのソースがリポジトリのmainブランチ（ソースブランチはmain）にあり、公開ソースがカスタムGitHub Actionsワークフローを使用した公開用に設定されていることを前提としています。

目標は次のとおりです。

  1. mainに新しいプルリクエストが作成されると、サイトが正常にビルドされることを確認するアクションがあり、実際にはデプロイされません。このジョブはtest-deployと呼ばれます。
  2. プルリクエストがmainブランチにマージされた場合、または誰かがmainブランチに直接プッシュした場合、ビルドされてGitHub Pagesにデプロイされます。このジョブはdeployと呼ばれます。

GitHub Actionsを使用してドキュメントをデプロイするための2つの方法があります。デプロイリポジトリの場所に基づいて、以下の関連するタブを選択してください。

  • ソースリポジトリとデプロイリポジトリは同じリポジトリです。
  • デプロイリポジトリは、ソースとは異なるリモートリポジトリです。このシナリオの手順では、公開ソースがgh-pagesブランチであることを前提としています。

同じワークフローファイルに両方のジョブを定義できますが、元のdeployワークフローは常にPRチェックスイートの状態にスキップ済みとしてリストされます。これは実際の状態を表しておらず、レビュープロセスに価値をもたらしません。そのため、代わりに別々のワークフローとして管理することを提案します。

GitHubアクションファイル

以下の2つのワークフローファイルを追加します。

セットアップのパラメータを調整してください

これらのファイルは、Yarn を使用していることを前提としています。npm を使用している場合は、cache: yarn、yarn install --frozen-lockfile、yarn build をそれぞれ cache: npm、npm ci、npm run build に変更してください。

Docusaurus プロジェクトがリポジトリのルートにない場合は、デフォルトの作業ディレクトリ を設定し、パスを適宜調整する必要がある場合があります。

.github/workflows/deploy.yml
name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main
    # Review gh actions docs if you want to further define triggers, paths, etc
    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on

jobs:
  build:
    name: Build Docusaurus
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn

      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Build website
        run: yarn build

      - name: Upload Build Artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: build

  deploy:
    name: Deploy to GitHub Pages
    needs: build

    # Grant GITHUB_TOKEN the permissions required to make a Pages deployment
    permissions:
      pages: write # to deploy to Pages
      id-token: write # to verify the deployment originates from an appropriate source

    # Deploy to the github-pages environment
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
.github/workflows/test-deploy.yml
name: Test deployment

on:
  pull_request:
    branches:
      - main
    # Review gh actions docs if you want to further define triggers, paths, etc
    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on

jobs:
  test-deploy:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn

      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Test build website
        run: yarn build
サイトが正しくデプロイされない場合？

main ブランチにプッシュした後、サイトが目的の場所に公開されない場合（たとえば、「ここに GitHub Pages サイトはありません」と表示される場合、またはリポジトリの README.md ファイルが表示される場合）、次の手順を試してください。

  • 約3分待ってから更新してください。GitHub Pages が新しいファイルを取得するまでに数分かかります。
  • リポジトリのランディングページで、最新のコミットのタイトルの横に小さな緑色のチェックマークが表示されていることを確認してください。これは CI が成功したことを示しています。バツ印が表示されている場合は、ビルドまたはデプロイが失敗したことを意味し、ログを確認してデバッグ情報を調べる必要があります。
  • チェックマークをクリックし、「GitHub Pages へのデプロイ」ワークフローが表示されていることを確認してください。「pages build and deployment / deploy」などの名前は GitHub のデフォルトのワークフローであり、カスタムデプロイワークフローがまったくトリガーされなかったことを示しています。YAML ファイルが .github/workflows フォルダーに配置され、トリガー条件が正しく設定されていることを確認してください（たとえば、デフォルトブランチが「main」ではなく「master」の場合は、on.push プロパティを変更する必要があります）。
  • リポジトリの設定 > Pages で、「ソース」（これはデプロイメントファイルのソースであり、私たちの用語における「ソース」とは異なります）が「gh-pages」+「/ (root)」に設定されていることを確認してください。これは、デプロイブランチとして gh-pages を使用しているためです。

カスタムドメインを使用している場合

Travis CI を使用したデプロイのトリガー​

継続的インテグレーション（CI）サービスは通常、新しいコミットがソースコントロールにチェックインされるたびにルーチンタスクを実行するために使用されます。これらのタスクは、単体テストと統合テストの実行、ビルドの自動化、npm へのパッケージの公開、Web サイトへの変更のデプロイなど、あらゆる組み合わせを行うことができます。Web サイトのデプロイを自動化するために必要なことは、Web サイトが更新されるたびに yarn deploy スクリプトを呼び出すだけです。次のセクションでは、人気の継続的インテグレーションサービスプロバイダーである Travis CI を使用してこれを行う方法について説明します。

  1. https://github.com/settings/tokens にアクセスして、新しい パーソナルアクセストークン を生成します。トークンを作成する際に、必要な権限を持つように repo スコープを付与します。
  2. GitHub アカウントを使用して、Travis CI アプリ をアクティブ化したいリポジトリに追加します。
  3. Travis CI ダッシュボードを開きます。URL は https://travis-ci.com/USERNAME/REPO のようになります。リポジトリの その他のオプション > 設定 > 環境変数 セクションに移動します。
  4. 新しく生成したトークンを値として持つ GH_TOKEN という名前の新しい環境変数を作成し、次に GH_EMAIL（メールアドレス）と GH_NAME（GitHub ユーザー名）を作成します。
  5. リポジトリのルートに .travis.yml を作成し、以下を記述します。
.travis.yml
language: node_js
node_js:
  - 18
branches:
  only:
    - main
cache:
  yarn: true
script:
  - git config --global user.name "${GH_NAME}"
  - git config --global user.email "${GH_EMAIL}"
  - echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
  - yarn install
  - GIT_USER="${GH_NAME}" yarn deploy

これで、新しいコミットが main に追加されるたびに、Travis CI はテストスイートを実行し、すべてが合格すると、yarn deploy スクリプトを介して Web サイトがデプロイされます。

Buddy を使用したデプロイのトリガー​

Buddy は、ポータルを GitHub Pages を含むさまざまな環境に自動的にデプロイできる使いやすい CI/CD ツールです。

プロジェクトの選択したブランチに変更をプッシュするたびに、Web サイトの新しいバージョンを自動的にデプロイするパイプラインを作成するには、次の手順に従います。

  1. https://github.com/settings/tokens にアクセスして、新しい パーソナルアクセストークン を生成します。トークンを作成する際に、必要な権限を持つように repo スコープを付与します。
  2. Buddy アカウントにサインインして、新しいプロジェクトを作成します。
  3. Git ホスティングプロバイダーとして GitHub を選択し、Web サイトのコードを含むリポジトリを選択します。
  4. 左側のナビゲーションパネルを使用して、パイプラインビューに切り替えます。
  5. 新しいパイプラインを作成します。名前を定義し、トリガーモードを プッシュ時 に設定し、パイプラインの実行をトリガーするブランチを選択します。
  6. Node.js アクションを追加します。
  7. アクションのターミナルに次のコマンドを追加します。
GIT_USER=<GH_PERSONAL_ACCESS_TOKEN>
git config --global user.email "<YOUR_GH_EMAIL>"
git config --global user.name "<YOUR_GH_USERNAME>"
yarn deploy

この単純なパイプラインを作成した後、選択したブランチにプッシュされた新しいコミットごとに、yarn deploy を使用して Web サイトが GitHub Pages にデプロイされます。このガイド を読んで、Docusaurus の CI/CD パイプラインの設定についてさらに学習してください。

Azure Pipelines の使用​

  1. まだ行っていない場合は、Azure Pipelines にサインアップしてください。
  2. 組織を作成します。組織内でプロジェクトを作成し、GitHub からリポジトリを接続します。
  3. https://github.com/settings/tokens にアクセスして、repo スコープを持つ新しい パーソナルアクセストークン を生成します。
  4. プロジェクトページ（https://dev.azure.com/ORG_NAME/REPO_NAME/_build のようになります）で、次のテキストを使用して新しいパイプラインを作成します。また、編集をクリックして、新しく生成したトークンを値として持つ GH_TOKEN という名前の新しい環境変数を作成し、次に GH_EMAIL（メールアドレス）と GH_NAME（GitHub ユーザー名）を作成します。それらをシークレットとしてマークすることを確認してください。または、リポジトリのルートに azure-pipelines.yml という名前のファイルを追加することもできます。
azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self
    persistCredentials: true

  - task: NodeTool@0
    inputs:
      versionSpec: '18'
    displayName: Install Node.js

  - script: |
      git config --global user.name "${GH_NAME}"
      git config --global user.email "${GH_EMAIL}"
      git checkout -b main
      echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
      yarn install
      GIT_USER="${GH_NAME}" yarn deploy
    env:
      GH_NAME: $(GH_NAME)
      GH_EMAIL: $(GH_EMAIL)
      GH_TOKEN: $(GH_TOKEN)
    displayName: Install and build

Drone の使用​

  1. プロジェクトの デプロイキー になる新しい SSH キーを作成します。
  2. 秘密キーと公開キーに具体的な名前を付け、他の SSH キー を上書きしないようにします。
  3. https://github.com/USERNAME/REPO/settings/keys にアクセスし、新しく生成した公開キーを貼り付けることで、新しいデプロイキーを追加します。
  4. Drone.io ダッシュボードを開き、ログインします。URL は https://cloud.drone.io/USERNAME/REPO のようになります。
  5. リポジトリをクリックし、リポジトリのアクティブ化をクリックし、新しく生成した秘密キーの値を使用して git_deploy_private_key という名前のシークレットを追加します。
  6. リポジトリのルートに .drone.yml を作成し、以下のテキストを記述します。
.drone.yml
kind: pipeline
type: docker
trigger:
  event:
    - tag
- name: Website
  image: node
  commands:
    - mkdir -p $HOME/.ssh
    - ssh-keyscan -t rsa github.com >> $HOME/.ssh/known_hosts
    - echo "$GITHUB_PRIVATE_KEY" > "$HOME/.ssh/id_rsa"
    - chmod 0600 $HOME/.ssh/id_rsa
    - cd website
    - yarn install
    - yarn deploy
  environment:
    USE_SSH: true
    GITHUB_PRIVATE_KEY:
      from_secret: git_deploy_private_key

これで、新しいタグを GitHub にプッシュするたびに、このトリガーによって Drone CI ジョブが開始され、Web サイトが公開されます。

Flightcontrol へのデプロイ​

Flightcontrol は、Git リポジトリから直接 Web アプリを AWS Fargate に自動的にビルドしてデプロイするサービスです。従来の PaaS の制限を受けることなく、インフラストラクチャの検査と変更を自由に実行できます。

まずは、Flightcontrolの段階的なDocusaurusガイドに従って始めましょう。

Koyebへのデプロイ​

Koyebは、開発者フレンドリーなサーバーレスプラットフォームで、グローバルにアプリをデプロイできます。このプラットフォームを使用すると、Gitベースのデプロイ、ネイティブな自動スケーリング、グローバルエッジネットワーク、組み込みのサービスメッシュとディスカバリーを備えたDockerコンテナ、ウェブアプリ、APIをシームレスに実行できます。KoyebのDocusaurusデプロイガイドを参照して開始してください。

Renderへのデプロイ​

Renderは、完全に管理されたSSL、カスタムドメイン、グローバルCDN、Gitリポジトリからの継続的な自動デプロイを備えた無料の静的サイトホスティングを提供しています。RenderのDocusaurusデプロイガイドに従って、数分で開始できます。

Qoveryへのデプロイ​

Qoveryは、AWS、Digital Ocean、Scalewayアカウント上で動作するフルマネージドクラウドプラットフォームで、静的サイト、バックエンドAPI、データベース、cronジョブ、その他のすべてのアプリを1つの場所にホストできます。

  1. Qoveryアカウントを作成します。まだアカウントをお持ちでない場合は、Qoveryダッシュボードにアクセスしてアカウントを作成してください。
  2. プロジェクトを作成します。
    • 「プロジェクトの作成」をクリックして、プロジェクト名を入力します。
    • 「次へ」をクリックします。
  3. 新しい環境を作成します。
    • 「環境の作成」をクリックして、名前（例：ステージング、本番）を入力します。
  4. アプリケーションを追加します。
    • 「アプリケーションの作成」をクリックし、名前を入力して、Docusaurusアプリが配置されているGitHubまたはGitLabリポジトリを選択します。
    • メインブランチ名とルートアプリケーションパスを定義します。
    • 「作成」をクリックします。アプリケーションが作成された後
    • アプリケーションの設定に移動します。
    • ポートを選択します。
    • Docusaurusアプリケーションで使用されているポートを追加します。
  5. デプロイ
    • あとは、アプリケーションに移動して「デプロイ」をクリックするだけです。

Deploy the app

以上です。ステータスを確認し、アプリがデプロイされるまで待ちます。ブラウザでアプリケーションを開くには、アプリケーションの概要で「アクション」と「開く」をクリックします。

Hostmanへのデプロイ​

Hostmanを使用すると、静的ウェブサイトを無料でホストできます。Hostmanはすべてを自動化するため、リポジトリを接続してこれらの簡単な手順に従うだけです。

  1. サービスを作成します。

    • Docusaurus静的ウェブサイトをデプロイするには、ダッシュボードの左上隅にある「作成」をクリックし、「フロントエンドアプリまたは静的ウェブサイト」を選択します。

  2. デプロイするプロジェクトを選択します。

    • GitHub、GitLab、またはBitbucketアカウントでHostmanにログインしている場合、プライベートなプロジェクトを含むプロジェクトのリポジトリが表示されます。

    • デプロイするプロジェクトを選択します。プロジェクトファイルを含むディレクトリ（例：website）が含まれている必要があります。

    • 別のリポジトリにアクセスするには、「別のリポジトリを接続」をクリックします。

    • Gitアカウントの資格情報を使用してログインしなかった場合は、ここで必要なアカウントにアクセスし、プロジェクトを選択できます。

  3. ビルド設定を構成します。

    • 次に、「ウェブサイトのカスタマイズ」ウィンドウが表示されます。フレームワークのリストから「静的ウェブサイト」オプションを選択します。

    • 「アプリを含むディレクトリ」は、ビルド後にプロジェクトファイルを含むディレクトリを指します。手順2でウェブサイトの内容（またはmy_website）ディレクトリを含むリポジトリを選択した場合は、空のままにしておくことができます。

    • Docusaurusの標準ビルドコマンドは次のとおりです。

      npm run build

    • 必要に応じてビルドコマンドを変更できます。&&で区切られた複数のコマンドを入力できます。

  4. デプロイ。

    • 「デプロイ」をクリックしてビルドプロセスを開始します。

    • 開始されると、デプロイログが表示されます。コードに問題がある場合、問題の原因を指定する警告またはエラーメッセージがログに表示されます。通常、ログには必要なすべてのデバッグデータが含まれています。

    • デプロイが完了すると、メール通知を受け取り、ログエントリも表示されます。完了しました！プロジェクトの準備ができました。

Surgeへのデプロイ​

Surgeは静的ウェブホスティングプラットフォームで、コマンドラインから数秒でDocusaurusプロジェクトをデプロイできます。Surgeへのプロジェクトのデプロイは簡単で無料です（カスタムドメインとSSL証明書を含む）。

次の手順に従って、Surgeを使用して数秒でアプリをデプロイします。

  1. まず、次のコマンドを実行してnpmを使用してSurgeをインストールします。 
    npm install -g surge
  2. プロジェクトのルートディレクトリで本番環境用のサイトの静的ファイルをビルドするには、次のコマンドを実行します。 
    npm run build
  3. 次に、プロジェクトのルートディレクトリ内でこのコマンドを実行します。 
    surge build/

Surgeの初回ユーザーには、コマンドラインからアカウントを作成するように促されます（1回のみ発生します）。

公開するサイトがbuildディレクトリにあることを確認します。ランダムに生成されたサブドメイン*.surge.sh サブドメインが常に与えられます（編集できます）。

ドメインの使用​

ドメイン名をお持ちの場合は、次のコマンドを使用してサイトをデプロイできます。

surge build/ your-domain.com

選択した方法に応じて、サイトはsubdomain.surge.shまたはyour-domain.comで無料でデプロイされます。

CNAMEファイルの設定​

次のコマンドを使用して、将来のデプロイのためにドメインをCNAMEファイルに保存します。

echo subdomain.surge.sh > CNAME

将来、surgeコマンドを使用して他の変更をデプロイできます。

Stormkitへのデプロイ​

静的ウェブサイト、シングルページアプリケーション（SPA）、サーバーレス関数のデプロイプラットフォームであるStormkitにDocusaurusプロジェクトをデプロイできます。詳細な手順については、このガイドを参照してください。

QuantCDNへのデプロイ​

  1. Quant CLIをインストールします。
  2. サインアップしてQuantCDNアカウントを作成します。
  3. quant initを使用してプロジェクトを初期化し、資格情報を入力します。 
    quant init
  4. サイトをデプロイします。 
    quant deploy

QuantCDNへのデプロイの詳細な例とユースケースについては、ドキュメントとブログを参照してください。

Layer0へのデプロイ​

Layer0は、ヘッドレスフロントエンドの開発、デプロイ、プレビュー、実験、監視、実行を行うオールインワンプラットフォームです。大規模で動的なウェブサイトと、EdgeJS（JavaScriptベースのコンテンツ配信ネットワーク）、予測プリフェッチ、パフォーマンス監視による最高のパフォーマンスに重点を置いています。Layer0は無料プランを提供しています。Layer0のDocusaurusデプロイガイドに従って、数分で開始できます。

Cloudflare Pagesへのデプロイ​

Cloudflare Pagesは、フロントエンド開発者が協力してウェブサイトをデプロイするためのJamstackプラットフォームです。この記事に従って、数分で開始できます。

Azure Static Web Appsへのデプロイ​

Azure Static Web Appsは、コードリポジトリからAzureにフルスタックウェブアプリを自動的にビルドおよびデプロイするサービスであり、CI/CDの開発者エクスペリエンスを簡素化します。Static Web Appsは、ウェブアプリケーションの静的アセットと動的（API）エンドポイントを分離します。静的アセットはグローバルに分散されたコンテンツサーバーから提供されるため、近くのサーバーを使用してクライアントがファイルをより高速に取得できます。動的APIは、イベント駆動型の関数ベースのアプローチを使用するサーバーレスアーキテクチャでスケーリングされるため、よりコスト効率が高く、オンデマンドでスケーリングされます。このステップバイステップガイドに従って、数分で開始できます。

Kinstaへのデプロイ​

Kinsta Static Site Hostingを使用すると、最大100個の静的サイトを無料でデプロイできます。カスタムドメインとSSL、月間100GBの帯域幅、260以上のCloudflare CDNロケーションが利用可能です。

KinstaでのDocusaurusの記事に従って、数回クリックするだけで開始できます。