Déploiement

Pour construire les fichiers statiques de votre site web pour la production, exécutez :

npm

npm run build

Yarn

yarn build

pnpm

pnpm run build

Une fois terminé, les fichiers statiques seront générés dans le répertoire build.

remarque

La seule responsabilité de Docusaurus est de construire votre site et d'émettre des fichiers statiques dans build.

C'est maintenant à vous de choisir comment héberger ces fichiers statiques.

Vous pouvez déployer votre site sur des services d'hébergement statiques tels que Vercel, GitHub Pages, Netlify, Render, Surge...

Un site Docusaurus est rendu de manière statique, et il peut généralement fonctionner sans JavaScript !

Configuration

Les paramètres suivants sont obligatoires dans docusaurus.config.js pour que Docusaurus optimise le routage et serve les fichiers à partir du bon emplacement :

Nom	Description
url	URL de votre site. Pour un site déployé sur https://my-org.com/my-project/`, urlesthttps://my-org.com/\.
baseUrl	URL de base pour votre projet, avec un slash à la fin. Pour un site déployé sur https://my-org.com/my-project/, baseUrl est /my-project/.

Tester votre construction en local

Il est important de tester votre construction avant de le déployer pour la production. Docusaurus possède une commande docusaurus serve pour cela :

npm

npm run serve

Yarn

yarn serve

pnpm

pnpm run serve

Par défaut, cela va charger votre site sur http://localhost:3000/.

Configuration du slash de fin

Docusaurus possède une config trailingSlash pour permettre de personnaliser les URL/liens et les modèles de noms de fichiers émis.

La valeur par défaut fonctionne généralement bien. Malheureusement, chaque hébergeur statique a un comportement différent, et déployer exactement le même site sur différents hôtes peut conduire à des résultats différents. En fonction de votre hôte, il peut être utile de modifier cette configuration.

astuce

Utilisez slorber/trailing-slash-guide pour mieux comprendre le comportement de votre hôte et configurer trailingSlash correctement.

Utilisation des variables d'environnement

Placer des informations potentiellement sensibles dans l'environnement est une pratique courante. Cependant, dans un site web typique de Docusaurus, le fichier docusaurus.config.js est la seule interface avec l'environnement Node.js (voir notre aperçu de l'architecture), alors que tout le reste—pages MDX, composants React... sont côté client et n'ont pas d'accès direct à la globale process. Dans ce cas, vous pouvez envisager d'utiliser customFields pour passer des variables d'environnement côté client.

docusaurus.config.js

// Si vous utilisez dotenv (https://www.npmjs.com/package/dotenv)
require('dotenv').config();

module.exports = {
  title: '...',
  url: process.env.URL, // Vous pouvez également utiliser des variables d'environnement pour contrôler les spécificités du site
  customFields: {
    // Mettez votre environnement personnalisé ici
    teamEmail: process.env.EMAIL,
  },
};

home.jsx

import useDocusaurusContext from '@docusaurus/useDocusaurusContext';

export default function Home() {
  const {
    siteConfig: {customFields},
  } = useDocusaurusContext();
  return <div>Contactez-nous via {customFields.teamEmail} !</div>;
}

Choix d'un hébergeur

Il existe quelques options d'hébergement courantes :

• L'auto-hébergement avec un serveur HTTP comme Apache2 ou Nginx;
• Fournisseurs de Jamstack, par exemple Netlify et Vercel. Nous les utiliserons comme références, mais le même raisonnement peut s'appliquer à d'autres fournisseurs.
• GitHub Pages. (Par définition, il s'agit aussi de Jamstack, mais nous le comparons séparément.)

Si vous n'êtes pas certain de savoir lequel choisir, posez-vous les questions suivantes :

Combien de ressources (temps de travail, argent ) suis-je prêt à investir dans ce projet ?

• 🔴 L'auto-hébergement est le plus difficile à mettre en place — vous aurez généralement besoin d'une personne expérimentée pour gérer cela. Les services Cloud ne sont presque jamais gratuits, et configurer un serveur sur place et le connecter au WAN peut être plus coûteux.
• 🟢 Les fournisseurs de Jamstack peuvent vous aider à configurer un site web fonctionnel en un rien de temps et offrent des fonctionnalités comme les redirections côté serveur qui sont facilement configurables. De nombreux fournisseurs offrent de généreux quotas de temps de construction, même pour les plans gratuits, que vous ne dépasserez presque jamais. Cependant, il reste en fin de compte limité, vous devrez payer une fois que vous aurez atteint la limite. Consultez la page tarifaire de votre fournisseur pour plus de détails.
• 🟡 Le workflow de déploiement des pages GitHub peut être fastidieux à configurer. (La preuve : regardez la longueur du Déploiement vers Github Pages !) Cependant, ce service (y compris la construction et le déploiement) est toujours gratuit pour les dépôts publics, et nous avons des instructions détaillées pour vous aider à le faire fonctionner.

De quelle configuration côté serveur ai-je besoin ?

• 🟢 Avec l'auto-hébergement, vous avez accès à toute la configuration du serveur. Vous pouvez configurer l'hôte virtuel pour qu'il serve différents contenus en fonction de l'URL de la requête; vous pouvez faire des redirections compliquées côté serveur; vous pouvez mettre une partie du site derrière l'authentification... Si vous avez besoin de nombreuses fonctionnalités côté serveur, hébergez votre site web.
• 🟡 Jamstack propose généralement certaines configurations côté serveur, par exemple le formatage des URL (slash de fin de chaîne), les redirections côté serveur...
• 🔴 Les Pages GitHub n'exposent pas les configurations côté serveur, à part l'application du HTTPS et la définition du CNAME.

Ai-je besoin de coopérer ?

• 🟡 Les services auto-hébergés peuvent atteindre le même effet que Netlify, mais avec beaucoup plus de lourdeur. En général, c'est une personne spécifique qui s'occupe du déploiement, et le processus n'est pas vraiment basé sur git, contrairement aux deux autres options.
• 🟢 Netlify et Vercel ont des aperçus de déploiement pour chaque pull request, ce qui est utile pour une équipe pour revoir le travail avant de le mettre en production. Vous pouvez également gérer une équipe avec un accès différent au déploiement.
• 🟡 Les pages GitHub ne peuvent pas faire des aperçus de déploiement d'une manière simple. Un dépôt ne peut être associé qu'à un seul déploiement du site. D'un autre côté, vous pouvez contrôler qui a accès en écriture au déploiement du site.

Il n'y a pas de solution miracle. Vous devez évaluer vos besoins et vos ressources avant de faire votre choix.

Auto-hébergement

Docusaurus peut être auto-hébergé en utilisant docusaurus serve. Changez de port en utilisant --port et --host pour changer d'hôte.

npm

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

Yarn

yarn serve --build --port 80 --host 0.0.0.0

pnpm

pnpm run serve -- --build --port 80 --host 0.0.0.0

attention

Ce n'est pas la meilleure option, par rapport à un fournisseur d'hébergement statique / CDN.

attention

Dans les sections suivantes, nous allons présenter quelques fournisseurs d'hébergement les plus courants et la manière dont ils doivent être configurés pour déployer les sites Docusaurus le plus efficacement possible. Certains textes sont fournis par des contributeurs externes. Docusaurus n'est lié à aucun des services. La documentation peut ne pas être à jour : les modifications récentes de leur API peuvent ne pas être reprises de notre côté. Si vous voyez du contenu obsolète, les PR sont les bienvenues.

Dans le même souci de mise à jour, nous avons cessé d'accepter les PR ajoutant de nouvelles options d'hébergement. Vous pouvez toutefois publier votre article sur un autre site (par exemple, votre blog ou le site officiel du fournisseur) et nous demander d'inclure un lien vers votre texte.

Déploiement sur Netlify

Pour déployer vos sites Docusaurus 2 sur Netlify, assurez-vous d'abord que les options suivantes sont correctement configurées :

docusaurus.config.js

module.exports = {
  url: 'https://docusaurus-2.netlify.app', // Url de votre site sans slash à la fin
  baseUrl: '/', // Répertoire de base de votre site relatif à votre depôt
  // ...
};

Ensuite, créez votre site avec Netlify.

Pendant que vous configurez le site, spécifiez les commandes de compilation et les répertoires comme suit :

• build command: npm run build
• publish directory: build

Si vous n'avez pas configuré ces options de compilation, vous pouvez toujours aller dans "Site settings" -> "Build deploy" après la création de votre site.

Une fois correctement configuré avec les options ci-dessus, votre site devrait être déployé et redéployé automatiquement lors de la fusion de votre branche de déploiement, qui est par défaut main.

attention

Certains sites Docusaurus placent le dossier docs à l'extérieur de website (probablement les anciens sites Docusaurus v1) :

repo           # racine git
├── docs       # fichiers MD
└── website    # racine Docusaurus

Si vous décidez d'utiliser le dossier website comme répertoire de base pour Netlify, Netlify ne déclenchera pas les builds lorsque vous mettrez à jour le dossier docs, et vous devrez configurer une commande personnalisée ignore :

website/netlify.toml

[build]
  ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../docs/"

attention

Par défaut, Netlify ajoute un slash final aux URL Docusaurus.

Il est recommandé de désactiver le paramètre Netlify Post Processing > Asset Optimization > Pretty Urls pour éviter les URL en minuscule, les redirections inutiles et les erreurs 404.

Faites très attention : la case à cocher globale Disable asset optimization est défectueuse et ne désactive pas vraiment le paramètre Pretty URLs en pratique. Veillez à *la décocher indépendamment**.

Si vous voulez garder le paramètre Pretty Urls de Netlify activé, ajustez la configuration trailingSlash de Docusaurus de manière appropriée.

Pour plus d'informations, consultez slorber/trailing-slash-guide.

Déploiement sur Vercel

Déployer votre projet Docusaurus sur Vercel vous fournira différents avantages dans les domaines de la performance et de la facilité d'utilisation.

Pour déployer votre projet Docusaurus avec un Vercel pour l'intégration Git, assurez-vous qu'il a été poussé dans un dépôt Git.

Importez le projet dans Vercel en utilisant Import Flow. Lors de l'importation, vous trouverez toutes les options pertinentes préconfigurées pour vous; cependant, vous pouvez choisir de modifier l'une de ces options, dont une liste peut être trouvée ici.

Après l'importation de votre projet, tous les pushs ultérieurs vers les branches généreront des Déploiements d'aperçu, et toutes les modifications apportées à la Branche de production (communément « main » ou « master ») donneront lieu à un Déploiement de production.

Déploiement sur GitHub Pages

Docusaurus fournit un moyen facile de publier sur GitHub Pages, qui est fourni gratuitement avec chaque dépôt GitHub.

Vue d'ensemble

Habituellement, il y a deux dépôts (au moins deux branches) impliqués dans un processus de publication : la branche contenant les fichiers source, et la branche contenant la sortie de construction à servir avec GitHub Pages. Dans le tutoriel suivant, ils seront appelés respectivement "source" et "deployment".

Chaque dépôt GitHub est associé à un service GitHub pages. Si le dépôt de déploiement est appelé my-org/my-project (où my-org est le nom de l'organisation ou le nom d'utilisateur), le site déployé apparaîtra à l'adresse https://my-org.github.io/my-projet/. En particulier, si le dépôt de déploiement s'appelle my-org/my-org.github.io (le dépôt des pages GitHub de l'organisation), le site apparaîtra sous https://my-org.github.io/.

info

Dans le cas où vous souhaitez utiliser votre domaine personnalisé pour GitHub Pages, créez un fichier CNAME dans le répertoire static. Tout ce qui se trouve dans le répertoire static sera copié à la racine du répertoire build pour le déploiement. Lorsque vous utilisez un domaine personnalisé, vous devriez pouvoir revenir de baseUrl: '/projectName/' à baseUrl: '/' et également définir votre url vers votre domaine personnalisé.

Vous pouvez vous référer à la documentation de GitHub Pages User, Organization, and Project Pages pour plus de détails.

Les pages GitHub récupèrent les fichiers prêts à être déployés (la sortie de docusaurus build) à partir de la branche par défaut (master / main, généralement) ou la branche gh-pages, et soit à partir de la racine, soit à partir du dossier /docs. Vous pouvez le configurer via Settings > Pages dans votre dépôt. Cette branche sera appelée "branche de déploiement".

Nous fournissons une commande docusaurus deploy qui vous aide à déployer votre site depuis la branche source vers la branche de déploiement en une seule commande : cloner, compiler et committer.

Paramètres de docusaurus.config.js

Tout d'abord, modifiez votre docusaurus.config.js et ajoutez les paramètres suivants :

Nom	Description
organizationName	L'utilisateur ou l'organisation GitHub qui possède le dépôt de déploiement.
projectName	Le nom du dépôt de déploiement.
deploymentBranch	Le nom de la branche de déploiement. La valeur par défaut est 'gh-pages' pour les pages GitHub des dépôts non organisationnels (projectName ne se terminant pas par .github.io). Sinon, cela doit être explicite comme un champ de configuration ou une variable d'environnement.

Ces champs ont également leurs équivalents sous forme de variables d'environnement qui ont une priorité plus élevée : ORGANIZATION_NAME, PROJECT_NAME et DEPLOYMENT_BRANCH.

attention

GitHub Pages ajoute par défaut un slash final aux URL Docusaurus. Il est recommandé de définir une config trailingSlash (true ou false, pas undefined).

Exemple :

docusaurus.config.js

module.exports = {
  // ...
  url: 'https://endiliey.github.io', // URL de votre site web
  baseUrl: '/',
  projectName: 'endiliey.github.io',
  organizationName: 'endiliey',
  trailingSlash: false,
  // ...
};

attention

Par défaut, les pages GitHub exécutent les fichiers publiés via Jekyll. Puisque Jekyll va se débarrasser de tous les fichiers qui commencent par _, il est recommandé de désactiver Jekyll en ajoutant un fichier vide nommé .nojekyll dans votre répertoire static.

Paramètres de l'environnement

Nom	Description
USE_SSH	Défini à true pour utiliser SSH au lieu du HTTPS par défaut pour la connexion au dépôt GitHub. Si l'URL du dépôt source est une URL SSH (par exemple git@github.com:facebook/docusaurus.git), USE_SSH est déduite comme étant à true.
GIT_USER	Le nom d'utilisateur pour un compte GitHub qui a un accès push au dépôt de déploiement. Pour vos propres dépôts, ce sera généralement votre nom d'utilisateur GitHub. Requis si vous n'utilisez pas SSH, et ignoré autrement.
GIT_PASS	Jeton d'accès personnel de l'utilisateur git (spécifié par GIT_USER), pour faciliter le déploiement non interactif (par exemple le déploiement continu)
CURRENT_BRANCH	La branche source. Habituellement, la branche sera main ou master, mais elle pourrait être n'importe quelle branche à l'exception de gh-pages. Si rien n'est défini pour cette variable, alors la branche courante à partir de laquelle docusaurus deploy est invoquée sera utilisée.

Les installations de GitHub Enterprise devraient fonctionner de la même manière que github.com ; il suffit de définir l'hôte GitHub Enterprise de l'organisation comme variable d'environnement :

Nom	Description
GITHUB_HOST	Le nom de domaine de votre site d'entreprise GitHub.
GITHUB_PORT	Le port de votre site d'entreprise GitHub.

Déployez

Enfin, pour déployer votre site sur GitHub Pages, exécutez :

Bash

GIT_USER=<GITHUB_USERNAME> yarn deploy

Windows

cmd /C "set "GIT_USER=<GITHUB_USERNAME>" && yarn deploy"

PowerShell

cmd /C 'set "GIT_USER=<GITHUB_USERNAME>" && yarn deploy'

attention

À partir d'août 2021, GitHub requiert que chaque connexion en ligne de commande utilise le jeton d'accès personnel au lieu du mot de passe. Lorsque GitHub vous demande votre mot de passe, entrez le PAT à la place. Voir la documentation de GitHub pour plus d'informations.

Alternativement, vous pouvez utiliser SSH (USE_SSH=true) pour vous connecter.

Déclenchement du déploiement avec GitHub Actions

Les GitHub Actions vous permettent d'automatiser, de personnaliser et d'exécuter vos flux de développement logiciel directement dans votre dépôt.

Les exemples de workflow ci-dessous supposent que la source de votre site web réside dans la branche main de votre dépôt (la branche source est main) et votre source de publication est configurée pour la branche gh-pages (la branche de déploiement est gh-pages).

Notre objectif est que :

1. Quand une nouvelle pull request est faite sur main, il y a une action qui assure que le site se construit avec succès, sans déploiement réel. Cette tâche sera appelée test-deploy.
2. Lorsqu'une pull request est fusionnée à la branche main ou quelqu'un pousse directement sur la branche main, cela construira et déploiera dans la branche gh-pages. Après cela, la nouvelle sortie sera distribuée sur le site des Pages GitHub. Cette tâche sera appelée deploy.

Voici deux approches pour déployer votre documentation avec GitHub Actions. Basé sur l'emplacement de votre branche de déploiement (gh-pages), choisissez l'onglet approprié ci-dessous :

• Le dépôt source et le dépôt de déploiement sont le même dépôt.
• Le dépôt de déploiement est un dépôt distant, différent de la source.

Le même

Bien que vous puissiez avoir les deux tâches définies dans le même fichier de workflow, le workflow original deploy sera toujours listé comme ignoré dans le statut de la suite de vérification du PR, il ne communique pas le statut réel et n'apporte aucune valeur au processus de révision. Nous proposons donc de les gérer en tant que workflow séparés.

Nous utiliserons une action de déploiement tierce populaire : peaceiris/actions-gh-pages.

Fichiers GitHub action

Ajoutez ces deux fichiers de workflow :

Ajustez les paramètres de votre configuration

Ces fichiers supposent que vous utilisez Yarn. Si vous utilisez npm, changez en conséquence cache: yarn, yarn install --frozen-lockfile, yarn build en cache: npm, npm ci, npm run build.

Si votre projet Docusaurus n'est pas à la racine de votre dépôt, vous devrez peut-être configurer un répertoire de travail par défaut, et ajuster les chemins en conséquence.

.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

permissions:
  contents: write

jobs:
  deploy:
    name: Deploy to GitHub Pages
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn

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

      # Popular action to deploy to GitHub Pages:
      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          # Build output to publish to the `gh-pages` branch:
          publish_dir: ./build
          # The following lines assign commit authorship to the official
          # GH-Actions bot for deploys to `gh-pages` branch:
          # https://github.com/actions/checkout/issues/13#issuecomment-724415212
          # The GH actions bot is used by default if you didn't specify the two fields.
          # You can swap them out with your own user credentials.
          user_name: github-actions[bot]
          user_email: 41898282+github-actions[bot]@users.noreply.github.com

.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@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn

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

Distant

Une publication inter-dépôt est plus difficile à mettre en place, car vous devez pousser vers un autre référentiel avec des contrôles de permission. Nous utiliserons SSH pour l'authentification.

1. Générez une nouvelle clé SSH. Comme cette clé SSH sera utilisée dans le CI, assurez-vous de ne pas saisir de passphrase.
2. Par défaut, votre clé publique devrait avoir été créée dans ~/.ssh/id_rsa.pub; ou utilisez le nom que vous avez fourni à l'étape précédente pour ajouter votre clé à GitHub deploy keys.
3. Copiez la clé dans le presse-papiers avec pbcopy < ~/.ssh/id_rsa.pub et collez-la comme une clé de déploiement dans votre dépôt de déploiement. Copiez le contenu du fichier si la ligne de commande ne fonctionne pas pour vous. Cochez la case Allow write access avant d'enregistrer votre clé de déploiement.
4. Vous aurez besoin de votre clé privée en tant que secret GitHub pour permettre à Docusaurus d'exécuter le déploiement pour vous.
5. Copiez votre clé privée avec pbcopy < ~/.ssh/id_rsa et collez un secret GitHub avec le nom GH_PAGES_DEPLOY sur votre dépôt de source. Copiez le contenu du fichier si la ligne de commande ne fonctionne pas pour vous. Enregistrez votre secret.
6. Créez votre fichier de documentation dans .github/workflows/. Dans cet exemple, c'est deploy.yml.
7. Vous devriez avoir essentiellement : le dépôt source avec le workflow GitHub défini avec la clé SSH privée comme GitHub Secret et votre dépôt de déploiement défini avec la clé SSH publique dans GitHub Deploy Keys.

Fichier GitHub action

attention

Veillez à remplacer actions@github.com par votre email GitHub et gh-actions par votre nom.

Ce fichier suppose que vous utilisez Yarn. Si vous utilisez npm, changez en conséquence cache: yarn, yarn install --frozen-lockfile, yarn build en cache: npm, npm ci, npm run build.

.github/workflows/deploy.yml

name: Deploy to GitHub Pages

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: write

jobs:
  test-deploy:
    if: github.event_name != 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn
      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Test build website
        run: yarn build
  deploy:
    if: github.event_name != 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn
      - uses: webfactory/ssh-agent@v0.5.0
        with:
          ssh-private-key: ${{ secrets.GH_PAGES_DEPLOY }}
      - name: Deploy to GitHub Pages
        env:
          USE_SSH: true
        run: |
          git config --global user.email "actions@github.com"
          git config --global user.name "gh-actions"
          yarn install --frozen-lockfile
          yarn deploy

Le site n'est pas correctement déployé ?

Après avoir poussé vers main, si vous ne voyez pas votre site publié à l'emplacement souhaité (par exemple, il indique « There isn't a GitHub Pages site here », ou il affiche le fichier README.md de votre dépôt), vérifiez ce qui suit :

• Il peut s'écouler quelques minutes avant que les pages GitHub ne détectent les nouveaux fichiers. Attendez environ 3 minutes et actualisez avant de conclure que cela ne fonctionne pas.
• Sur la page d'accueil de votre dépôt, vous devriez voir une petite coche verte à côté du titre du dernier commit, indiquant que le CI est réussi. Si vous voyez une croix, cela signifie que la construction ou le déploiement a échoué, et vous devez vérifier le journal pour plus d'informations de débogage.
• Cliquez sur la coche et assurez-vous que vous voyez un flux de travail « Deploy to GitHub Pages ». Des noms comme « pages build and deployment / deploy » sont des flux de travail par défaut de GitHub, ce qui indique que votre flux de travail de déploiement personnalisé qui a échoué, n'a pas du tout été déclenché. Assurez-vous que les fichiers YAML sont placés dans le dossier .github/workflows et que la condition de déclenchement est correctement définie (par exemple, si votre branche par défaut est "master" au lieu de "main", vous devez modifier la propriété on.push).
• Nous utilisons gh-pages comme branche de déploiement. Dans « Settings > Pages » de votre dépôt, assurez-vous que "Source" (qui est la source pour les fichiers de déploiement, et non "source" comme dans notre terminologie) est définie à "gh-pages" + "/ (root)".
• Si vous utilisez un domaine personnalisé, assurez-vous que l'enregistrement DNS pointe vers l'adresse IP des serveurs des pages GitHub.

Déclenchement du déploiement avec Travis CI

Les services d'intégration continue (CI) sont généralement utilisés pour effectuer des tâches routinières lorsque de nouveaux commits sont enregistrés dans le contrôle de source. Ces tâches peuvent être une combinaison de tests unitaires et de tests d'intégration, d'automatisation de la construction, de publication de paquets sur npm et de déploiement de modifications sur votre site Web. All you need to do to automate the deployment of your website is to invoke the yarn deploy script whenever your website is updated. The following section covers how to do just that using Travis CI, a popular continuous integration service provider.

1. Allez sur https://github.com/settings/tokens et générez un nouveau jeton d'accès personnel. Lors de la création du jeton, octroyez-lui la portée du repo afin qu'il dispose des autorisations dont il a besoin.
2. En utilisant votre compte GitHub, ajoutez l'application Travis CI au dépôt que vous souhaitez activer.
3. Ouvrez votre tableau de bord Travis CI. L'URL ressemble à https://travis-ci.com/USERNAME/REPO et naviguez vers la section More options > Setting > Environment Variables de votre dépôt.
4. Créez une nouvelle variable d'environnement nommée GH_TOKEN avec votre jeton nouvellement généré comme valeur, puis GH_EMAIL (votre adresse e-mail) et GH_NAME (votre nom d'utilisateur GitHub).
5. Créez un .travis.yml à la racine de votre dépôt avec les éléments suivants :

.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

Maintenant, chaque fois qu'un nouveau commit arrive dans main, Travis CI exécutera votre suite de tests et si tout se passe, votre site web sera déployé via le script yarn deploy.

Déclenchement du déploiement avec Buddy

Buddy est un outil CI/CD facile à utiliser qui vous permet d'automatiser le déploiement de votre portail dans différents environnements, notamment les pages GitHub.

Suivez ces étapes pour créer un pipeline qui déploie automatiquement une nouvelle version de votre site Web chaque fois que vous apportez des modifications à la branche sélectionnée de votre projet :

1. Allez sur https://github.com/settings/tokens et générez un nouveau jeton d'accès personnel. Lors de la création du jeton, octroyez-lui la portée du repo afin qu'il dispose des autorisations dont il a besoin.
2. Connectez-vous à votre compte Buddy et créez un nouveau projet.
3. Choisissez GitHub comme hébergeur git et sélectionnez le dépôt avec le code de votre site web.
4. À l'aide du panneau de navigation de gauche, basculez vers la vue Pipelines.
5. Créez un nouveau pipeline. Définissez son nom, définissez le mode de déclenchement à On push, et sélectionnez la branche qui déclenche l'exécution du pipeline.
6. Ajoutez une action Node.js.
7. Ajoutez ces commandes dans le terminal de l'action :

GIT_USER=<GH_PERSONAL_ACCESS_TOKEN>
git config --global user.email "<YOUR_GH_EMAIL>"
git config --global user.name "<YOUR_GH_USERNAME>"
yarn deploy

Après avoir créé ce pipeline simple, chaque nouveau commit poussé vers la branche que vous avez sélectionnée déploie votre site web sur GitHub Pages à l'aide de yarn deploy. Lisez ce guide pour en savoir plus sur la mise en place d'un pipeline CI/CD pour Docusaurus.

Utilisation de Azure Pipelines

1. Inscrivez-vous sur Azure Pipelines si vous ne l'avez pas déjà fait.
2. Créer une organisation. Au sein de l'organisation, créez un projet et connectez votre dépôt à partir de GitHub.
3. Allez sur https://github.com/settings/tokens et générez un nouveau jeton d'accès personnel avec la portée de repo.
4. Dans la page du projet (qui ressemble à https://dev.azure.com/ORG_NAME/REPO_NAME/_build), créez un nouveau pipeline avec le texte suivant. Aussi, cliquez sur modifier et ajoutez une nouvelle variable d'environnement nommée GH_TOKEN avec votre jeton nouvellement généré comme valeur, puis GH_EMAIL (votre adresse e-mail) et GH_NAME (votre nom d'utilisateur GitHub). Assurez-vous de les marquer comme secrets. Vous pouvez également ajouter un fichier nommé azure-pipelines.yml à la racine de votre dépôt.

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

Utilisation de Drone

1. Create a new SSH key that will be the deploy key for your project.
2. Name your private and public keys to be specific and so that it does not overwrite your other SSH keys.
3. Go to https://github.com/USERNAME/REPO/settings/keys and add a new deploy key by pasting in the public key you just generated.
4. Ouvrez votre tableau de bord Drone.io et connectez-vous. The URL looks like https://cloud.drone.io/USERNAME/REPO.
5. Click on the repository, click on activate repository, and add a secret called git_deploy_private_key with your private key value that you just generated.
6. Create a .drone.yml on the root of your repository with the below text.

.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

Maintenant, chaque fois que vous poussez un nouveau tag sur Github, ce déclencheur démarrera la tâche de drone CI pour publier votre site web.

Déploiement sur Koyeb

Koyeb is a developer-friendly serverless platform to deploy apps globally. La plateforme vous permet d'exécuter de manière transparente des conteneurs Docker, des applications Web et des API avec un déploiement basé sur git, une mise à l'échelle automatique native, un réseau périphérique mondial et un maillage et une découverte de services intégrés. Check out the Koyeb's Docusaurus deployment guide to get started.

Déploiement sur Render

Render offers free static site hosting with fully managed SSL, custom domains, a global CDN, and continuous auto-deploy from your Git repo. Get started in just a few minutes by following Render's guide to deploying Docusaurus.

Déploiement sur Qovery

Qovery is a fully-managed cloud platform that runs on your AWS, Digital Ocean, and Scaleway account where you can host static sites, backend APIs, databases, cron jobs, and all your other apps in one place.

1. Créez un compte Qovery. Visit the Qovery dashboard to create an account if you don't already have one.
2. Créez un projet.
   • Click on Create project and give a name to your project.
   • Click on Next.
3. Créez un nouvel environnement.
   • Click on Create environment and give a name (e.g. staging, production).
4. Ajoutez une application.
   • Click on Create an application, give a name and select your GitHub or GitLab repository where your Docusaurus app is located.
   • Définissez le nom de la branche principale et le chemin de l'application racine.
   • Click on Create. Après la création de l'application :
   • Navigate to your application Settings
   • Select Port
   • Ajoutez le port utilisé par votre application Docusaurus
5. Deploy All you have to do now is to navigate to your application and click on Deploy.

Voilà. Regardez le statut et attendez que l'application soit déployée. To open the application in your browser, click on Action and Open in your application overview.

Déploiement sur Hostman

Hostman allows you to host static websites for free. Hostman automatise tout, il vous suffit de connecter votre dépôt et de suivre des étapes faciles :

1. Créez un service.

   To deploy a Docusaurus static website, click Create in the top-left corner of your Dashboard and choose Front-end app or static website.

2. Sélectionnez le projet à déployer.

   Si vous êtes connecté à Hostman avec votre compte GitHub, GitLab ou Bitbucket, à ce stade, vous verrez le dépôt avec vos projets, y compris les projets privés.

   Choisissez le projet que vous souhaitez déployer. It must contain the directory with the project's files (e.g. website).

   To access a different repository, click Connect another repository.

   Si vous n'avez pas utilisé les informations d'identification de votre compte Git pour vous connecter, vous pourrez accéder au compte nécessaire maintenant, puis sélectionner le projet.

3. Configurez les paramètres de construction.

   Next, the Website customization window will appear. Choose the Static website option from the list of frameworks.

   The Directory with app points at the directory that will contain the project's files after the build. You can leave it empty if during Step 2 you selected the repository with the contents of the website (or my_website) directory.

   La « build command » pour Docusaurus sera :

   npm

   npm run build

   Yarn

   yarn build

   pnpm

   pnpm run build

   Vous pouvez modifier la commande de compilation si nécessaire. You can enter multiple commands separated by &&.

4. Déployez.

   Click Deploy to start the build process.

   Une fois qu'il aura démarré, vous entrerez dans le journal de déploiement. En cas de problème avec le code, vous obtiendrez des messages d'avertissement ou d'erreur dans le journal, précisant la cause du problème. Habituellement, le journal contient toutes les données de débogage dont vous aurez besoin.

   Une fois le déploiement terminé, vous recevrez une notification par mail et vous verrez également une note du journal. Terminé ! Votre projet est prêt.

Déploiement sur Surge

Surge is a static web hosting platform, it is used to deploy your Docusaurus project from the command line in a minute. Déployer votre projet sur Surge est facile et il est également gratuit (y compris un domaine personnalisé et SSL).

Déployez votre application en quelques secondes en utilisant surge avec les étapes suivantes :

1. Tout d'abord, installez Surge en utilisant npm en exécutant la commande suivante :
   npm

   npm install -g surge

   Yarn

   yarn global add surge

   pnpm

   pnpm add -g surge
2. Pour construire pour la production les fichiers statiques de votre site à la racine de votre projet, exécutez :
   npm

   npm run build

   Yarn

   yarn build

   pnpm

   pnpm run build
3. Ensuite, exécutez cette commande à l'intérieur du répertoire racine de votre projet :

   surge build/

La première fois, les utilisateurs de Surge seront invités à créer un compte à partir de la ligne de commande (cela ne se produit qu'une fois).

Confirm that the site you want to publish is in the build directory, a randomly generated subdomain *.surge.sh subdomain is always given (which can be edited).

Utiliser votre nom de domaine

Si vous avez un nom de domaine, vous pouvez déployer votre site en utilisant la commande :

surge build/ your-domain.com

Your site is now deployed for free at subdomain.surge.sh or your-domain.com depending on the method you chose.

Mise en place du fichier CNAME

Stockez votre domaine dans un fichier CNAME pour de futurs déploiements avec la commande suivante :

echo subdomain.surge.sh > CNAME

Vous pouvez déployer tout autre changement dans le futur avec la commande surge.

Déploiement sur QuantCDN

1. Install Quant CLI
2. Create a QuantCDN account by signing up
3. Initialize your project with quant init and fill in your credentials:

   quant init
4. Déployez votre site.

   quant deploy

See docs and blog for more examples and use cases for deploying to QuantCDN.

Déploiement sur Layer0

Layer0 is an all-in-one platform to develop, deploy, preview, experiment on, monitor, and run your headless frontend. Il est axé sur les sites Web dynamiques de grande taille et sur des performances de premier ordre grâce à EdgeJS (un réseau de diffusion de contenu basé sur JavaScript), à la récupération anticipée prédictive et au contrôle des performances. Layer0 offre un niveau gratuit. Get started in just a few minutes by following Layer0's guide to deploying Docusaurus.

Déploiement sur Cloudflare Pages

Cloudflare Pages is a Jamstack platform for frontend developers to collaborate and deploy websites. Get started within a few minutes by following this article.

Déploiement sur Azure Static Web Apps

Azure Static Web Apps est un service qui construit et déploie automatiquement des applications web complètes sur Azure directement à partir du dépôt de code, simplifiant ainsi l'expérience du développeur pour le CI/CD. Static Web Apps sépare les ressources statiques de l'application Web de ses points de terminaison dynamiques (API). Les ressources statiques sont servies par des serveurs de contenu répartis dans le monde entier, ce qui permet aux clients de récupérer plus rapidement les fichiers en utilisant des serveurs à proximité. Les API dynamiques sont mises à l'échelle avec des architectures sans serveur, en utilisant une approche basée sur des fonctions événementielles qui est plus rentable et évolue à la demande. Démarrez en quelques minutes en suivant ce guide étape par étape.