Gagner en vélocité en adoptant le Dev Environment As A service

Dans un précédent article nous présentions Google Cloud Shell, un environnement de développement provisionné à la demande sur le Cloud.
Sa configuration standard apporte un gain de temps substantiel aux développeurs en capacité de coder avec un simple navigateur web. Nous pointions toutefois des limites dans cette approche, la principale étant qu’elle ne change pas notre manière d’envisager les tâches de développement en comparaison d’un environnement local. Autrement dit, nous avons déporté notre machine de développement sur le Cloud mais nos méthodes de travail restent les mêmes.
Ces dernières sont pourtant limitées par des routines inefficaces.
Cloner un dépôt, penser à tirer les branches, changer de branche pour une revue de code... autant de pratiques qui nous semblent naturelles mais qui sont en réalité des freins à un flow de développement.

Des routines de développement inefficaces

En tant que développeur, arriver sur un nouveau projet demande un certain effort et il est très rare d’être en capacité d’y contribuer dès les premiers jours. Il va falloir passer par des routines indispensables mais chronophages :

S’assurer d’avoir une machine adaptée aux ressources requises par le projet, cloner le dépôt de code en local, installer les runtimes et librairies nécessaires, se prendre les premiers murs dus à des incompatibilités de versions, questionner le sénior de l’équipe, etc.

En réalité, tout cela se reproduit à plus ou moins la même échelle dès que l’on change de branche dans un même projet. Ce qui nous paraît normal se révèle être une suite d’actions qui a un coût sur le long terme. Des outils vont nous aider à mitiger ces problèmes.
On pense par exemple aux IDEs, gestionnaires de dépendances, Ansible et consort mais tout cela prend du temps à configurer si tant est qu’on les utilise correctement. Un modèle différent est nécessaire.  

Penser “Pure Git”

Le modèle de pensée porté par Git est la raison de son succès. Centré autour d’un système de branches simple mais puissant, il permet aux développeurs de travailler en vase clos tout en bénéficiant des développements existants. La flexibilité de Git a très rapidement permis l’émergence de pratiques comme le feature branching.
En poussant le concept, on arrive à des modes de fonctionnement type “une fonctionnalité, une branche”.

Aujourd’hui il est très rare de travailler avec du code dont l’historique n’est pas géré par Git (dans le cas contraire, c’est que vraisemblablement on vous a payé pour assurer la migration de ce code vers Git).

La théorie veut donc que la création d’une branche soit gratuite tout comme le passage d’une branche à une autre.
Ce qui est vrai en local pour la création l’est moins pour le changement de branche.

Nous l’évoquions plus haut, un environnement local a une certaine lourdeur illustrée par exemple par des incompatibilités de versions de librairies entre différentes branches ou des installations supplémentaires pour lancer l'application.
La synchronisation du code entre sa version locale et celle du dépôt distant est un autre point d’accroche. Par définition, un clone est un fork consensuel d’un dépôt Git distant et il est à la charge du développeur de maintenir ce fork à jour avec un certain nombre de commandes Git. Routines qui encore une fois ralentissent notre flow de développement. On devine des incompatibilités conceptuelles entre ces deux mondes qui nuisent à l’activité de code. Des plugins et outils permettent une réconciliation plus ou moins heureuse des deux mondes mais les observations faites demeurent.
Nous parlerons d’impedance mismatch entre le modèle de Git et l’environnement de développement local qui n’a pas la même agilité.

La technologie des conteneurs améliore ce constat car il devient possible de conteneuriser l’environnement de développement qu’on “attachera” à une branche Git. C’est l’idée portée par l’extension containers de VSCode. Vous ne codez pas réellement en local, mais dans un container avec une runtime déjà configurée pour le projet et du code issue de votre clone local.
Nous résolvons alors une partie de la problématique liée à l’environnement de développement mais nous gardons les problèmes liés au concept de fork.

Bref, on se porterait mieux à se passer d’un clone local de dépôt.
Un scénario idéal serait de coder “directement” sur la branche qui nous intéresse sans la rapatrier en local et dans un environnement ad-hoc conteneurisé et configuré.

L’offre GitPod

Gitpod est un service qui réconcilie le modèle Git avec la notion d’environnement de développement. Dans ce modèle de pensée branche et environnement de développement sont synonymes.

Plus précisément, Gitpod donne accès au code applicatif par la notion de workspace i.e un environnement de développement éphémère. Un développeur y accède par une simple connexion HTTPs et pourra développer un code à jour depuis un VSCode adapté.

Bien qu’un workspace puisse avoir une durée de vie supérieure à la tâche de développement qui en est à l’origine, la philosophie de Gitpod est de penser sa durée de vie au strict minimum et préférer en créer à la volée en fonction des besoins.

Sous le capot, le workspace est un environnement de développement conteneurisé associé à une URL. Il a un cycle de vie que l’on pourra configurer avec un fichier gitpod.yaml sourcé dans votre projet Git. C’est utile notamment pour préciser les actions de “prebuild” et leur déclencheur pour mitiger le problème de coldstart lors de son provisioning.

Un nouveau rapport au code

Le workspace Gitpod répond aux problématiques liées à l’incompatibilité entre la pensée Git et la nature de l’environnement local. Il va aussi plus loin en enrichissant le travail en équipe par sa capacité à être partagé par URL.
Au même titre que l’on peut partager du code statique sur Github/Gitlab/Bitbucket, Gitpod permet de partager des environnements de développement pour coder collectivement en temps réel.

On peut aussi penser à exposer le port d’un serveur pour servir de backend éphémère ou d'environnement pour les tests fonctionnels.
Bref, les scénarios de collaboration sur le code sont enrichis et simplifiés.

Des intégrations aux écosystèmes existants

Pour utiliser Gitpod il est nécessaire de passer par une authentification aux services Github, Gitlab et Bitbucket utilisés en tant que fournisseur d’identité.
Cette identité sert à Gitpod pour l’accès à vos projets ainsi que de base pour son modèle de permission. L’intégration va plus loin avec le workspace qui comprend le contexte de sa création (branche, pull/merge request) en adaptant les capacités du workspace à ce dernier.

Son usage de VSCode est un autre point intéressant. N’utilisant pas un pur VSCode, Gitpod en garantit toutefois la parité en termes de fonctionnalité et s’appuie sur la marketplace Eclipse Open VSX.

Enfin, s’engager sur une offre payante Gitpod n’est pas contraignant. Ce n’est qu’une surcouche à des services Git existants. Le service ne crée pas de vendor-lockin vis-à-vis de votre code.

Comment commencer ?

Il est très simple de commencer à utiliser Gitpod. Cela tient en ce préfixe d’URL, gitpod.io/#,  que vous ajoutez à l’url d’un repository Github, Gitlab ou Bitbucket.
Vous pouvez tout aussi bien utiliser le dashboard ou le plugin Gitpod Firefox/Chrome.

Si l’interface du navigateur Web ne vous convient pas, il est possible de connecter votre IDE (parmi une liste compatible) à votre workspace pour retrouver vos raccourcis clavier préférés.

Côté pricing, Gitpod propose une offre avec free-tier plutôt agressive qui peut soulever des questions quant à la rentabilité du modèle.
Les économies envisageables se reportent sur votre machine qui ne requiert plus nécessairement  autant de compute ni de mémoire pour faire tourner vos applications.

Des limitations et points d’attention

Vous l’aurez compris, Gitpod nécessite une connexion internet constante et stable. Un réseau 4G, dans la plupart des cas suffisant, ne cache pas le besoin d’une connexion stable et donc d’une solution alternative avec des sources présentes localement. Autrement dit, l’usage de Gitpod ne doit pas être synonyme de ne plus pouvoir développer en local.

On veillera donc à synchroniser la configuration des deux approches pour ne pas être complètement dépaysé en passant d’un environnement à l’autre (configurations et clés SSH différentes par exemple). La notion de volume est une solution possible en considérant le cas de l’extension container sur VSCode. Ce n’est plus possible sur Gitpod car hébergé sur un réseau que nous ne maîtrisons pas.
Toutefois des outils de management de dotfiles permettent de transformer des dépôts Github en point de vérité de la configuration de l’ensemble de vos environnements.
Chezmoi en est un parfait exemple et on peut penser à l’installer sur les images de vos environnement Gitpod pour en lancer une synchronisation avec votre dépôt de Dotfile à chaque phase d’init. En somme, du Gitops appliqué à vos configurations.

On notera que les fichiers renseignés dans le .gitignore et contenant des clés personelles n’ont plus de sens dans Gitpod qui n’expose que les fichiers poussés sur les branches. Les variables d'environnement Gitpod offrent une alternative mais nous perdons en agilité de développement.

Tous ces précédents points apparaissent comme anecdotiques comparés aux questions de sécurité soulevées par Gitpod. Le partage de workspace, bien que pratique, peut être sujet à des inquiétudes légitimes vis-à-vis de la fuite de données sensibles type secret ou clé. L’impossibilité actuelle de le désactiver peut rendre impossible l’usage de Gitpod dans un contexte professionnel.  

Pour conclure

Les métiers de l’IT  ont connu de nombreuses évolutions vis à vis de leur rapport au code. D’abord centrées sur l’outillage et les IDEs, l’apparition de Git aura complètement modifié les routines de développement. Pourtant, là où nous pensions avoir atteint un plateau d’efficacité, se démocratise la technologie des conteneurs qui peu à peu infuse sur la notion d’environnement de développement. Désormais, ce n’est plus un seul environnement de développement que nous manipulons mais une infinité. Gitpod a bien saisi cette nouvelle donne et propose une abstraction au-dessus de services et technologies bien établies pour rendre l’expérience du code fluide et “consommable”. Plus important encore que l’offre, c’est cette vision qui nous intéresse et qui semble partie pour prendre de l’ampleur dans les années qui viennent.

Aller plus loin

1. Chez Wescale nous parlions de l’extension containers de VSCode ici.
2. Le projet OpenVSX choisit comme marketplace des extensions Gitpod
3. Le serveur OpenVSCode développé par Gitpod
4. Chezmoi un outil de management de configuration ainsi qu’un article Wescale de présentation