Introduction à GitHub Codespaces

Dans cet article, nous faisons le point sur tout ce qu’il faut savoir sur GitHub Codespaces, une plateforme qui vaut la peine d’être maîtrisée car elle transforme la façon de travailler des développeurs grâce à un environnement de développement instantané, dans le cloud. Nous passerons en revue le cycle de vie d’un Codespace afin que vous compreniez les différentes étapes du processus. Nous verrons aussi comment personnaliser votre propre codespace pour l’adapter à votre façon de travailler et à vos besoins.

Pas d’inquiétude si vous ne connaissez pas encore Git et GitHub. Suivez notre cours GitHub Concepts pour apprendre à créer un dépôt, un README et bien d’autres fondamentaux. Ne passez pas non plus à côté de notre cours Foundations of Git pour démarrer avec les bases du contrôle de version. 

Qu’est-ce qu’un GitHub Codespace ?

Un GitHub Codespace est un environnement de développement dans le cloud qui permet d’écrire, tester et déboguer du code directement en ligne, sans configuration locale complexe. Lorsqu’un codespace est créé, il lance un conteneur Docker exécuté sur une machine virtuelle, préconfiguré avec les outils, bibliothèques et dépendances nécessaires au projet. Une autre caractéristique notable de GitHub Codespaces est son intégration avec des IDE comme Visual Studio Code, comme nous le verrons plus loin.

Workflow d’un codespace. Source : GitHub

Comprendre le cycle de vie de GitHub Codespaces

Comprendre GitHub Codespaces suppose de connaître le cycle de vie d’un codespace. Chaque phase implique des actions spécifiques qui influent sur votre expérience et sur l’utilisation des ressources.

Phase de création

Vous avez deux options principales pour créer un codespace : partir d’un projet existant ou démarrer un nouveau projet. Pour un projet existant, vous créerez généralement un codespace à partir d’une branche de dépôt, et le codespace sera lié à la branche que vous sélectionnez. Pour un nouveau projet, vous pouvez utiliser un modèle. Un modèle est utile car il fournit un environnement préconfiguré pour lancer rapidement un projet. 

À noter : bien que les modèles soient surtout utilisés pour les nouveaux projets, si vous travaillez sur un projet existant et souhaitez appliquer des réglages spécifiques d’un modèle, vous pouvez reprendre la configuration du modèle pour enrichir votre environnement. C’est aussi une option. 

Trouver Codespaces dans le menu GitHub. Image de l’auteur

Par conception, le workflow et l’interaction avec Git et les branches sont similaires à ceux que vous auriez en local. Dans les deux cas, vous publiez votre projet dans un dépôt GitHub et vous veillez à pousser vos modifications sur GitHub. 

Phase de reconstruction

Créer un nouveau codespace est une alternative au fait de reconstruire un codespace. Dans certaines situations, toutefois, reconstruire présente des avantages, d’où l’intérêt de comprendre la différence. Par exemple, la reconstruction permet d’appliquer des mises à jour à la configuration du conteneur sans perdre le travail présent dans votre répertoire /workspaces. De plus, lors d’une reconstruction, GitHub Codespaces réutilise les images en cache des précédents builds, ce qui accélère le processus en évitant de réinstaller les bibliothèques.

Reconstruire le conteneur. Image de l’auteur

Phase d’arrêt

On arrête un codespace car, une fois l’environnement en pause, aucune ressource n’est consommée, ce qui aide à maîtriser les coûts. Gardez à l’esprit que l’exécution d’un codespace génère des frais CPU, tandis qu’un codespace arrêté n’entraîne que des frais de stockage. 

Il est important de savoir que si vous n’arrêtez pas explicitement un codespace, il continuera de tourner jusqu’à l’expiration due à l’inactivité. La durée d’inactivité avant arrêt est un paramètre personnalisable que nous verrons dans la section suivante. Autre point important : fermer simplement l’onglet du navigateur n’arrête pas le codespace. C’est une erreur fréquente.

Arrêter un codespace. Image de l’auteur

Phase de suppression

Une fois votre projet terminé, supprimez le codespace pour éviter des frais de stockage inutiles. C’est aussi une bonne pratique pour garder un espace de travail organisé.

Vous pouvez soit pousser vos modifications vers une branche distante avant la suppression, soit écarter totalement les changements non validés. Par ailleurs, les codespaces inactifs pendant une durée définie seront supprimés automatiquement. L’objectif est d’aider les développeurs à gérer leur stockage et leurs coûts. Le choix de la durée avant suppression automatique est une autre personnalisation que nous verrons ci-dessous.

Supprimer un codespace. Image de l’auteur

Personnaliser GitHub Codespaces

L’un des atouts de GitHub Codespaces est son haut niveau de personnalisation. Vous pouvez choisir une configuration ou des outils spécifiques. Globalement, on peut distinguer deux catégories : les personnalisations destinées à adapter votre espace de travail à votre style, et celles qui vous aident à gérer les ressources et à contenir les coûts. 

Personnaliser votre environnement

Commençons par la personnalisation de l’environnement. Les développeurs apprécient les réglages adaptés à leur façon de travailler. La plupart de ces paramètres sont accessibles en cliquant sur votre photo de profil pour ouvrir le menu des paramètres, comme illustré ci-dessous. 

Ouvrir le menu des paramètres. Image de l’auteur

Synchronisation des paramètres

Commencez par garantir la cohérence entre vos réglages sur VS Code pour desktop et le client web. Activez la synchronisation des paramètres (Settings Sync) pour que toute modification faite d’un côté s’applique de l’autre. C’est très pratique lorsque vous alternez entre environnements.

Activer Settings Sync. Image de l’auteur

Des conflits peuvent survenir en cas d’écarts entre les paramètres cloud et locaux, ou si l’une de vos machines est restée hors ligne un moment. En cas de conflit, vous pourrez écraser soit avec les réglages locaux, soit avec ceux du cloud, ou choisir plus finement quoi conserver. 

Renommer un codespace

GitHub attribue un nom d’affichage à chaque nouveau codespace. Vous n’aurez probablement pas envie de conserver ce nom généré automatiquement, surtout si vous en avez plusieurs. Essayez d’adopter un nom qui reflète l’objectif du projet et facilite la navigation.  

Renommer un codespace. Image de l’auteur

Sachez qu’en plus du nom d’affichage, chaque codespace possède un nom permanent que vous ne pouvez pas modifier. Ce nom permanent correspond au nom d’affichage suivi d’une suite de caractères aléatoires. L’objectif est d’assurer un identifiant unique. Portez attention à ce nom permanent si vous utilisez l’interface en ligne de commande GitHub. Il peut aussi être utile si vous devez contacter l’assistance GitHub. Vous pouvez le retrouver en ouvrant le codespace dans le navigateur : le sous-domaine correspond au nom permanent. 

Changer de shell

Si vous ouvrez un nouveau codespace dans l’application desktop de VS Code, le shell lancé dépend de vos réglages locaux. Avec le client web de VS Code, bash s’ouvre par défaut. Vous pouvez toujours changer pour zsh ou fish, puis enregistrer ce choix dans vos paramètres pour ouvrir votre shell préféré à chaque fois. 

Changer de shell. Image de l’auteur

Définir l’éditeur par défaut

Vous pouvez également choisir votre éditeur de code favori. Si, comme moi, vous aimez Visual Studio Code, configurez vos paramètres pour lancer VS Code à chaque création ou ouverture de codespace. Vous pouvez choisir entre VS Code, JetBrains et JupyterLab.

Choisir un éditeur par défaut. Image de l’auteur

Gérer les ressources et les performances

Voyons maintenant quelques réglages liés à l’allocation de ressources et aux performances.

Changer le type de machine

Vous pouvez sélectionner ou modifier le matériel sous-jacent de votre environnement. Par exemple, passer à une machine avec plus de CPU, de RAM ou de stockage. Ainsi, votre codespace dispose des ressources adaptées à la tâche, sans excès. Attention au type de machine distante utilisé, car chaque type correspond à une tranche de facturation différente.  

Sélectionner un type de machine préféré. Image de l’auteur

Notez que vous ne pouvez changer le type de machine que pour des codespaces publiés : si vous créez un codespace à partir d’un modèle non lié à un dépôt GitHub, vous n’aurez pas cette option. De même, si vous faites partie d’une organisation, le changement peut être restreint selon la politique en vigueur. 

Personnaliser le délai d’inactivité

Par défaut, GitHub Codespaces s’arrête automatiquement après 30 minutes, mais vous pouvez l’ajuster dans vos paramètres personnels. Le délai maximal est de quatre heures. L’objectif est d’éviter de faire tourner inutilement des codespaces inactifs.

Modifier le délai d’inactivité. Image de l’auteur

Configurer la suppression automatique

Les codespaces inactifs sont supprimés après un certain temps, afin de libérer des ressources. Vous pouvez définir la durée de conservation des codespaces arrêtés avant suppression, avec une rétention maximale de 30 jours. 

Définir la durée de rétention. Image de l’auteur

Choisir la région géographique

Vous pouvez définir, dans vos paramètres de profil, une région géographique par défaut pour l’hébergement de vos GitHub Codespaces. Choisir une région proche de chez vous peut améliorer les performances (temps de chargement, latence) et vous permet également de localiser le stockage de vos données pour respecter d’éventuelles exigences de résidence des données.

Changer de région. Image de l’auteur

GitHub.dev vs GitHub Codespaces

Si vous connaissez GitHub, vous avez peut-être déjà entendu parler de GitHub.dev, et vous vous demandez en quoi il diffère de GitHub Codespaces. 

GitHub.dev est un éditeur de code léger dans le navigateur, tandis que GitHub Codespaces fournit un véritable environnement de développement permettant d’exécuter et de tester votre code. En d’autres termes, GitHub.dev, plus limité, est pensé pour des modifications de code rapides. 

GitHub Codespaces s’intègre aussi avec des IDE comme VS Code, et les changements de paramètres entre cloud et local peuvent être synchronisés via Settings Sync, comme nous l’avons vu. Les développeurs remarqueront également que les environnements GitHub.dev ne sont pas persistants : votre travail n’est pas conservé entre les sessions sauf si vous validez manuellement vos modifications dans le dépôt. À l’inverse, avec GitHub Codespaces, vos changements sont sauvegardés même si vous fermez ou arrêtez votre codespace. 

En résumé, privilégiez GitHub Codespaces pour les projets d’ampleur et les workflows complexes, car il offre la puissance d’un environnement de développement sans configuration ni gestion de ressources sur votre machine personnelle.  

À mesure que le travail devient plus distribué et flexible, des outils comme GitHub Codespaces joueront un rôle clé dans l’avenir du développement logiciel. Concrètement, GitHub Codespaces résout plusieurs problèmes majeurs : il vous permet de coder immédiatement, quelles que soient les spécifications de votre machine locale ; il vous donne accès à un environnement de développement depuis n’importe quel appareil ; et il facilite la collaboration d’équipe dans des environnements identiques. 

Pour aller plus loin, lisez les articles DataCamp suivants :

• The GitHub Certification Guide for Data Professionals 
• Understanding GitHub: What is GitHub and How to Use It 
• GitHub Actions and MakeFile: A Hands-on Introduction 

Enfin, écoutez l’épisode du podcast DataCamp, The Future of Programming with Kyle Daigle, COO at GitHub. Il y aborde l’état du codage assisté par l’IA et la façon dont il voit évoluer le secteur.