Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Reprise d’activité pour GitHub Codespaces

Cet article fournit des conseils pour un scénario de reprise d’activité, dans lequel une région entière connaît une panne en raison d’une catastrophe naturelle majeure ou d’une interruption de service importante.

Nous travaillons dur pour garantir que GitHub Codespaces est toujours disponible pour vous. Toutefois, des forces indépendantes de notre volonté ont parfois un impact sur le service, susceptible d’entraîner des interruptions de service non planifiées.

Bien que les scénarios de récupération d’urgence soient rares, nous vous recommandons de vous préparer à la possibilité d’une panne d’une région entière. Si une région entière est confrontée à une interruption de service, les copies localement redondantes de vos données sont temporairement indisponibles.

L’aide suivante fournit des options sur la façon de gérer les interruptions de service dans toute la région où votre codespace est déployé.

Remarque : vous pouvez réduire l’impact potentiel des pannes à l’échelle du service en effectuant souvent un envoi (push) à des dépôts distants.

Option 1 : Créer un codespace dans une autre région

Dans le cas d’une panne régionale, nous vous suggérons de recréer votre codespace dans une région non affectée pour continuer à travailler. Ce nouveau codespace inclura toutes les modifications apportées jusqu’à votre dernier envoi (push) à GitHub. Pour plus d’informations sur la définition manuelle d’une autre région, consultez « Définition de votre région par défaut pour GitHub Codespaces ».

Vous pouvez optimiser le temps de récupération en configurant un devcontainer.json dans le dépôt du projet, qui vous permet de définir les outils, runtimes, infrastructures, paramètres d’éditeur, extensions et autres configurations nécessaires pour restaurer automatiquement l’environnement de développement. Pour plus d’informations, consultez « Présentation des conteneurs de développement ».

Option 2 : Attendre la récupération

Dans ce cas, aucune action n’est requise de votre part. Soyez assuré que nous travaillons assidûment à la restauration de la disponibilité du service.

Vous pouvez vérifier l’état actuel du service sur le tableau de bord État.

Option 3 : Cloner le dépôt localement ou le modifier dans le navigateur

Bien que GitHub Codespaces offre l’avantage d’un environnement de développement préconfiguré, votre code source doit toujours être accessible via le dépôt hébergé sur GitHub.com. En cas de panne de GitHub Codespaces, vous pouvez toujours cloner le dépôt localement ou modifier des fichiers dans l’éditeur du navigateur GitHub. Pour plus d’informations, consultez « Modification des fichiers ».

Si cette option ne configure pas un environnement de développement pour vous, elle vous permet d’apporter des modifications à votre code source en fonction des besoins pendant que vous attendez la résolution de l’interruption de service.

Option 4 : Utiliser l’extension Dev Containers et Docker pour un environnement conteneurisé local

Si votre dépôt contient un devcontainer.json, envisagez d’utiliser l’extension Dev Containers dans Visual Studio Code pour générer un build et l’attacher à un conteneur de développement local pour votre dépôt. Le temps de configuration de cette option varie en fonction de vos spécifications locales et de la complexité de la configuration de votre conteneur de développement. Pour plus d’informations, consultez « Développement à l’intérieur d’un conteneur » dans la documentation VS Code.

Remarque : assurez-vous que votre configuration locale répond aux exigences minimales avant de tenter cette option.