ℹ️ Cet article n’est pas sponsorisé.

Introduction

Github a lancé lors de l’été 2021 un service payant appelé Github Codespaces . Ce service propose des conteneurs de développement dans le cloud, à la demande et facturé à la durée d’utilisation et d’inactivité.

Un conteneur de développement est un environnement de développement clé en main. Cela permet d’avoir un environnement complet sans installer sur votre poste vos librairies, dépendences, sdk, etc. Tout sera préinstallé directement dans le conteneur.

Ces conteneurs sont “jetables”. Vous pouvez en créer un nouveau en quelques clics et supprimer ceux que vous avez créés aussi facilement.

Pour en bénéficier il faut bien entendu que votre projet soit sur Github, et également être abonné à l’abonnement Teams (ou Enterprise) de Github. Et il vous faudra activer la fonctionnalité dans votre organisation.

Sous le capot

Comme rien n’est magique je vais vous expliquer ce qu’il y a derrière ce service.

Codespace ⇒ Docker

Qui dit conteneur dit généralement docker (même s’il y a des alternatives, comme podman par exemple) mais en l’occurrence c’est bien docker qui est utilisé par Github Codespaces .

Le conteneur par défaut contient déjà de quoi développer avec les technologies suivantes : Python, Node.js, JavaScript, TypeScript, C++, Java, .NET, PHP, PowerShell, Go, Ruby, and Rust.

Sa configuration est ici: https://github.com/microsoft/vscode-dev-containers/blob/main/containers/codespaces-linux/.devcontainer/base.Dockerfile

Vous aurez ensuite accès à une image de ce container sur la branche de votre projet choisie à travers un VSCode dans votre navigateur. Il est aussi possible d’utiliser en VSCode classique avec le plugin Github.codespaces .

Code editor ⇒ VSCode

VScode, l’étoile montante des IDE, Open Source et poussé par Microsoft depuis 2015. Il y a de grandes chances que si vous lisiez ceci il soit déjà installé sur votre poste 💻

Vous pouvez synchroniser vos settings VSCode en vous connectant avec un compte Github ou Microsoft.

💸 Coût/Performances

Pour 8h d’activité avec un 8 core/16GB, cela revient à 5.76$.
Lorsque vous êtes inactif pendant 30 minutes, le Codespace se stoppe mais garde l’état de votre conteneur, donc vous ne perdrez pas votre code non commit/push 😉.
La facturation d’un Codespace inactif se fait à l’espace disque utilisé durant la période d’inactivité. Cela dépend donc de la taille de votre projet.

Tips : Pensez à supprimer vos conteneurs inutilisés régulièrement depuis cette page https://github.com/codespaces . Votre compte en banque et la planète vous remercieront 🙂

⚙️ Configuration

Il est possible de configurer pour Codespace à votre guise.

Deux fichiers vous permettent de personnaliser le Codespace:

• Un fichier .devcontainer/devcontainer.json ⇒ Personnaliser le Codespace et VSCode
• Un fichier .devcontainer/Dockerfile ⇒ Personnaliser le conteneur docker

Vous pouvez configurer l’un ou l’autre ou les deux selon vos besoins.

Personnalisation du conteneur (.devcontainer/Dockerfile)

Vous pouvez très bien revoir complètement le conteneur pour subvenir à vos besoins plus spécifiques comme par exemple démarrer un conteneur de base de données à l’intérieur, spécifier les versions de vos langages de développement désirées ou installer des outils divers.

Petit exemple

# [Choice] Java version (use -bullseye variants on local arm64/Apple Silicon): 11, 17, 11-bullseye, 17-bullseye, 11-buster, 17-buster
ARG VARIANT="17-bullseye"
FROM mcr.microsoft.com/vscode/devcontainers/java:0-${VARIANT}
# [Choice] Node.js version: none, lts/*, 16, 14, 12, 10
ARG NODE_VERSION="none"
RUN if [ "${NODE_VERSION}" != "none" ]; then su vscode -c "umask 0002 && . /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi

Ce fichier Dockerfile permet de choisir la version Java qui vous intéresse. Par défaut c’est hélas encore un JDK 11 qui est disponible dans le Dockerfile de base, c’est pourquoi nous précisons ici un JDK 17.

À combiner avec ces paramètres dans le fichier devcontainer.json.

Personnalisation du Codespace (.devcontainer/devcontainer.json)

Vous pouvez préinstaller vos extensions favorites comme ceci dans le fichier devcontainer.json.

Tips : Trouver le nom des extensions de votre VSCode avec cette commande

code --list-extensions

Port forwarding

Quand vous démarrez votre application, Codespace détecte automatiquement le port à forward (s’il est affiché dans les logs de démarrage de votre application) et le map, vous permettant ainsi d’y accéder avec une url du type :

https://username-organization-projectname-codespaceid-port.githubpreview.dev

Le cas échéant vous pouvez spécifier les ports à forward. Vous pouvez également renseigner un label et définir un comportement lorsque le port est automatiquement forward.

Par exemple, notify fera apparaitre un popup vous proposant d’ouvrir l’url.

Secrets

Codespace inclut un système de secrets, à configurer dans les settings Github de votre projet. Ces secrets sont mis à disposition en variable d’environnement du conteneur créé. Très pratique pour ne pas commiter de secrets dans votre repository, même pour l’environnement de dev 😉

Note : Les secrets sont injectés au premier lancement de votre Codespace, il faudra donc le supprimer et en recréer un nouveau si vous effectuez des changements.

dotfiles

Il est possible d’exécuter des scripts à certain moment du cycle de vie de votre conteneur, comme après la création ou le démarrage. C’est très pratique pour installer vos dépendences npm par exemple 🙂

Utilisation

🌎 Browser vs Web

Vous avez le choix entre utiliser l’environnement Web ou bien connecter votre VSCode local au conteneur de dev.

Il y a des différences notables, la principale étant la gestion des raccourcis claviers. En effet votre navigateur prend la main sur certains raccourcis ce qui est parfois assez gênant. Il y a également moins de plugins compatibles sur la version web.

Pour relier votre VSCode local à un conteneur de développement, il vous faudra installer l’extension Github Codespaces de VSCode https://marketplace.visualstudio.com/items?itemName=GitHub.codespaces

Partager son environnement

Il est possible d’exposer les ports de votre application soit à n’importe qui, soit uniquement aux membres de votre organisation. Par défaut la visibilité de votre port est privée.

Cette fonctionnalité s’avère très pratique pour partager avec vos collègues votre environnement de développement afin de leur présenter vos développements en cours.

🔒 Sécurité/Réseau

Si vous avez besoin d’accéder à des ressources derrière un réseau privé, vous pouvez le faire . La documentation à ce sujet est encore toute fraîche et elle n’existait pas lors de la mise en place de Codespace chez notre client (cf plus bas).

Le cycle de vie de votre Codespace

On peut distinguer 5 états différents : Création/Démarrage/Actif/Extinction/Inactif

Pas grand choses à dire si ce n’est qu’au bout d’un certain temps d’inactivité ( 30 min par défaut ) votre Codespace passe en statut inactif et qu’il est possible d’exécuter des scripts lors d’un changement d’état ( postCreate, postStart ).

Cas d’usage client

Si je vous parle de ce sujet aujourd’hui c’est parce que j’ai pu le mettre en place chez un client d’Attineos.

Ce client développe un produit SaaS entièrement configurable. Un repository Github est créé pour configurer l’instance de chaque client. C’est une équipe d’analyste qui s’occupe de la configuration. Ils ne sont pas nécessairement familiers avec le développement web et les langages utilisés.

Nous leur mettons donc à disposition un environnement clé en main et avons configuré un script postCreate.sh qui installe les dépendences du monorepo, du projet frontend web et installe gradle dans la partie api.

Pour couronner le tout, npm run dev lancera simultanément l’API et le front end.

Grâce à Github Codespaces, nous n’avons pas besoin d’expliquer aux analystes comment installer un environnement ou comment configurer sa machine. Il est également très facile de passer d’un Codespace à un autre.

Pour l’équipe de développeur, cela nous permet d’éviter d’avoir autant de repositories que de client sur notre machine. En 3 clics, notre instance de dev avec l’environnement client est prête.

Un Codespace étant lié à une branche il est donc possible de développer sur plusieurs branches simultanément !

Petite comparaison avec la concurrence

Docker Development Environments (Preview)

Docker propose en preview une fonctionnalité appelée “Development Environments” qui semblerait être gratuite mais la fonctionnalité de partage semble payante. Ce n’est pas vraiment un environnement virtuel dans le sens où tout tourne sur votre machine. Vous ne louer pas de la puissance de calcul dans un cloud. Il faut avoir Docker Desktop d’installé sur son poste et Il n’y a pas d’image docker préconfigurée avec les technologies classiques. Cette technologie s’adresse donc uniquement aux développeurs avec une bonne connaissance de docker.

Amazon AWS Cloud9

Amazon propose des environnements de développement virtualisés où vous devez installer tout ce dont vous avez besoin vous-même. Cela peut être pratique si vous avez besoin de puissance de calcul.

Vous ne pouvez coder qu’à travers le navigateur et leur IDE AWS Cloud9. Ce service s’adresse à des utilisateurs avancés.

Conclusion

Personnellement j’adore vraiment le concept d’environnement de développement préconfiguré jetable. C’est vraiment pratique d’arriver sur un projet sans rien avoir à configurer.

J’ai toujours été contre les VDI (Virtual Desktop Infrastructure) pour les développeurs car je ne supporte pas la frustration liée à la latence, mais ici la latence est transparente étant donné qu’on ne stream pas un OS entier. Il vous suffit donc d’un navigateur web pour pouvoir développer et ça c’est plutôt génial !

Les plus :

• Depuis la mise en place en septembre 2021 la documentation a déjà bien évolué, c’est donc que le projet évolue vite et est très suivi.
• Le partage de son environnement en deux clicks
• Facilité de prise en main, même pour les non développeurs

Ce qui est améliorable :

• La durée de lancement : Actuellement à chaque création, un docker build est effectué, ce qui est lent, mais visiblement une private preview pour prébuilder votre Codespace est en cours depuis peu
• Pouvoir exécuter un script avant la destruction du Codespace
• Mieux gérer le feedback des erreurs d’exécution de ses scripts : Il faut ouvrir les logs soit même

Pour en savoir plus: https://github.com/features/codespaces

🙏 Merci d’avoir lu entièrement cet article et si vous avez des questions vous pouvez me retrouver sur les réseaux sociaux Twitter et LinkedIn !