Space
The intelligent code collaboration platform
Space is pivoting to SpaceCode, focused on Git hosting and code reviews. Learn more →
Immersion dans les environnements de développement de Space
JetBrains Space permet de lancer des environnements de développement à distance. Une puissante machine virtuelle dédiée exécute un conteneur Docker qui a accès au code source du projet et fournit des composants de backend à votre éditeur de code local. Vous pouvez utiliser ces machines distantes pour développer au lieu de votre ordinateur local.
L’utilisation des environnements de développement de Space offre de nombreux avantages, notamment la possibilité de standardiser l’environnement de développement de votre équipe pour éviter de perdre du temps à configurer les machines locales. De plus, vous pouvez exécuter des tâches de préparation et créer un snapshot contenant toutes les dépendances de packages nécessaires et un index de projet préconfiguré prêt à être utilisé.
Dans cet article, nous allons vous présenter les différentes options de personnalisation des environnements de développement de Space et vous expliquer comment personnaliser un environnement en fonction des besoins de votre équipe.
Créer un environnement de développement
Avant de vous faire découvrir les options de personnalisation, faisons un point rapide sur le processus de développement dans les environnements de Space.
Pour commencer, vous pouvez lancer un environnement de développement dans tout référentiel Git appartenant à votre organisation Space en cliquant sur Open in IDE. Vous pouvez aussi créer un environnement de développement pour une demande de fusion, ce qui évite d’avoir à cloner du code manuellement et de télécharger des dépendances sur votre ordinateur local pour vérifier et tester les modifications.
Conseil : vous pouvez migrer ou mettre en miroir un référentiel Git depuis GitHub ou BitBucket et le mettre à disposition dans Space, ce qui inclut toutes les branches et balises, ainsi que les commits. Cela permet de pouvoir utiliser les environnements de développement de Space avec un référentiel existant.
Nous proposons trois types d’instances de machine virtuelle en fonction de la taille de votre projet et du niveau de puissance requis : Regular (4 cœurs de processeur, 8 Go de RAM), Large (8 cœurs de processeur, 16 Go de RAM) ou Extra Large (16 cœurs de processeur, 32 Go de RAM).
Ensuite, vous devez sélectionner l’IDE que vous souhaitez utiliser : IntelliJ IDEA avec JetBrains Gateway (qui peut être téléchargé avec Toolbox App) ou JetBrains Fleet. La prise en charge d’autres IDE basés sur IntelliJ sera effective prochainement.
Vous remarquerez également deux autres éléments dans cette boîte de dialogue : le snapshot de préparation et le conteneur dev servant à démarrer votre IDE distant. Dans l’exemple ci-dessus, il n’y a aucun snapshot de préparation n’est présent (nous y reviendrons dans un moment) et l’image Docker par défaut sert de conteneur pour le démarrage de votre IDE.
Lorsque vous cliquez sur Create, Space lance votre IDE dans le cloud. Quand la machine virtuelle est configurée et que le backend de l’IDE est prêt, JetBrains Gateway (ou Fleet) s’ouvre et s’y connecte.
Le backend IntelliJ IDEA s’exécute à présent dans le cloud de Space et la connexion est assurée par un client léger : JetBrains Gateway.
Pour la plupart des projets, cela suffit pour commencer à coder. Mais dans cet exemple précis, il manque plusieurs éléments :
- Il faut encore télécharger le bon JDK, comme indiqué par l’avertissement dans l’éditeur.
- Il faut exécuter
mvnw compile
pour télécharger les dépendances et synchroniser le projet dans l’IDE.
Cela suffirait probablement pour un environnement de développement à usage unique, mais si toute votre équipe doit travailler dans ce référentiel, mieux vaut personnaliser l’environnement et s’assurer que toutes les dépendances sont présentes dès le début. Voyons comment procéder !
Personnalisation du Dockerfile de l’environnement de développement
Par défaut, Space exécute votre environnement de développement en utilisant l’image de conteneur par défaut basée sur le système d’exploitation Ubuntu et incluant Git, cURL, Docker, Docker Compose et OpenJDK.
Pour installer les outils et bibliothèques dont vous avez besoin, vous pouvez ajouter un Dockerfile personnalisé à votre projet. Selon l’IDE que vous utiliserez, vous devrez créer ./.jb-gateway/Dockerfile
(pour IntelliJ IDEA avec JetBrains Gateway) ou ./.fleet/Dockerfile
(pour Fleet).
Dans le cas de ce projet, nous allons personnaliser l’environnement en le basant sur Ubuntu 20.04, et installer plusieurs outils de ligne de commande, parmi lesquels Git, curl et Docker. Nous allons également ajouter plusieurs versions d’OpenJDK et utiliser la version 16 par défaut afin que l’environnement de développement puisse l’utiliser.
FROM ubuntu:20.04 ENV DEBIAN_FRONTEND=noninteractive ENV LC_ALL=C.UTF-8 RUN apt-get update && apt-get install -y apt-utils apt-transport-https RUN apt-get install -y \ # Utilities \ curl unzip wget software-properties-common socat man-db gnupg2 pass lsof \ # VCS \ git \ # JVM \ openjdk-8-jre-headless openjdk-11-jdk-headless openjdk-16-jdk-headless openjdk-17-jdk-headless maven \ # Docker docker docker-compose \ && rm -rf /var/lib/apt/lists/* ENV JAVA_HOME=/usr/lib/jvm/java-16-openjdk-amd64
L’ajout d’un Dockerfile personnalisé est soumis à plusieurs conditions :
- Le système d’exploitation doit être une distribution Linux basée sur glibc (par exemple, CentOS 7+, Debian 9+ ou Ubuntu 20.04+).
- Vous devez installer Git, OpenSSH (si vous souhaitez utiliser un référentiel Git distant) et
lsof
(si vous avez besoin de transfert de ports dans l’IDE). - Le conteneur doit s’exécuter en tant que racine (sans utilisateur non racine dans le Dockerfile).
Veuillez noter que le Dockerfile est spécifique à la branche. Cela permet notamment de tester les personnalisations dans une autre branche sans que cela n’affecte les autres développeurs de votre équipe, et de mettre à jour les outils dans une branche de fonctionnalité.
Lorsque vous validez et envoyez en push ce Dockerfile personnalisé vers votre référentiel de projet, Space l’utilisera comme image de base lors de la création d’un nouvel environnement de développement dans cette branche.
Une fois cet environnement de développement personnalisé lancé, vous verrez que la bonne version du JDK sera accessible pour l’IDE. Toutefois, les projets IntelliJ IDEA et Maven doivent toujours être synchronisés. C’est là qu’intervient le script de préparation.
Préparation de l’environnement de développement
Vous pouvez réduire le temps nécessaire à l’IDE pour résoudre les dépendances du projet, créer des index et exécuter d’autres activés en arrière-plan, en créant un snapshot de préparation. Dans notre exemple, l’exécution de mvnw compile
et l’indexation du projet nous aideraient à obtenir un environnement de développement prêt à être utilisé.
Les snapshots de préparation sont créés par Space Automation. En ajoutant un fichier .space.kts
, vous pouvez non seulement configurer l’intégration continue (CI) pour votre projet, mais aussi la façon dont l’environnement de développement devrait être préparé.
Voici un exemple de fichier .space.kts
définissant une tâche qui s’exécute toutes les nuits, télécharge toutes les branches Git, puis exécute les étapes de création d’un snapshot de préparation avec IntelliJ IDEA :
job("Dev Environment Warmup - Gateway") { startOn { schedule { cron("0 5 * * *") } } git { depth = UNLIMITED_DEPTH refSpec = "refs/*:refs/*" } warmup(ide = Ide.IJGateway) { scriptLocation = "warmup.sh" } }
Le paramètre scriptLocation
est facultatif. S’il est omis, Space Automation clone le référentiel Git de votre projet et gère l’indexation du projet dans l’IDE. S’il est ajouté, vous pouvez créer un script de préparation, par exemple warmup.sh
, et exécuter mvnw compile
pour télécharger toutes les dépendances Maven dans votre snapshot de préparation, ou encore exécuter npm install
. Voici un exemple de script de préparation warmup.sh
:
#!/bin/bash ./mvnw compile
Le script warmup.sh
doit être validé dans votre référentiel avec des autorisations d’exécution. Pour ce faire, exécutez git update-index --chmod=+x warmup.sh
.
Une fois que Space Automation a terminé le travail de préparation, les nouveaux environnements de développement ainsi générés utilisent le Dockerfile personnalisé que nous avons créé plus tôt, et montent le snapshot de préparation que nous venons de créer, avec les index de projet et les dépendances prêts à l’emploi.
D’autre part, vous pouvez gérer et supprimer les snapshots dont vous n’avez plus besoin via le menu Dev Environments du projet.
Image de conteneur, snapshot de préparation ou les deux ?
Nous avons vu comment personnaliser l’image de conteneur d’un environnement de développement et comment créer un snapshot de préparation. Mais où faut-il exécuter tel ou tel type de tâche ?
De manière générale, la configuration de l’environnement et du système d’exploitation se fait avec une image de conteneur personnalisée, alors que les travaux de préparation sont destinés aux tâches propres au projet, telles que le téléchargement des dépendances binaires et la préparation de l’IDE pour votre projet.
Conclusion
L’utilisation d’images de conteneurs personnalisées vous permet de standardiser l’environnement de développement de votre équipe et de gagner du temps. De plus, en créant un snapshot de préparation incluant les dépendances de package téléchargées et les index de projet déjà générés, vous pouvez commencer à travailler avec l’environnement de développement plus rapidement.
Essayez Space et ses environnements de développement ! Nous avons hâte de savoir ce que vous en pensez !
Auteur de l’article original en anglais :