RETOUR
Existe-t-il un moyen idéal de gérer plusieurs environnements pour un grand nombre de personnes sur une seule machine ? Notre expert Java Bartłomiej connaît la réponse !
Examinons l'environnement de travail typique d'un éditeur de logiciels. Vous avez quelques clients qui ont des environnements différents. Certains préfèrent MySQL, d'autres Postgres. Une version de votre application nécessite Java 11, et un autre Java 17. Frontend a besoin de npm 12 ou 16 parce que vous utilisez différentes versions de angulaire. Enfin, vous avez ce tableau tridimensionnel qui contient des combinaisons de toutes vos bases de données, versions backend et frontend. Ça a l'air grave, mais un jour votre patron vous dit...
La situation décrite ci-dessus n'est pas rare. La migration entre les versions d'un langage ou d'un cadre, les mises à jour des bases de données ou simplement des exigences différentes de la part des clients peuvent bouleverser toutes les configurations. Nous devrions disposer d'une solution qui nous aide à gérer ces changements, une solution qui corresponde à quelques hypothèses et/ou exigences et/ou objectifs :
Dans cet article, je me concentrerai sur trois domaines. Le premier concerne les outils pour Java et la JVM. Le deuxième concerne les outils à usage général. Le troisième est la façon d'utiliser docker pour atteindre nos objectifs.
Lorsque vous êtes un Développeur Java ou, plus généralement, vous travaillez avec Technologies JVMVous pouvez alors utiliser SDKMAN !. Il s'agit d'un outil très agréable et facile à utiliser qui prend en charge de nombreuses bibliothèques, frameworks et langages.
Le processus d'installation de SDKMAN ! C'est assez simple. Vous devez courir :
curl -s "https://get.sdkman.io" | bashet ensuite
source "$HOME/.sdkman/bin/sdkman-init.sh"Vous pouvez désormais gérer vos Java, Scala et Maven versions.
Dans cet exemple, nous installerons et mettrons à jour la version de quelques outils. Il ne s'agit que d'un petit sous-ensemble d'outils disponibles.
Supposons que votre nouveau projet utilise Java 17. Vous n'avez pas de Java installée. Vous voulez l'installer et, en plus, ajouter un outil Maven Daemon pour rendre les constructions plus rapides. Vous devez donc également installer Maven. Pour ce faire, vous devez exécuter trois commandes simples :
$ sdk install java 17-open
$ sdk install maven 3.8.4
$ sdk install mvnd 0.7.1À la fin de l'installation de chaque outil, il vous sera demandé si vous souhaitez le mettre par défaut :
Vous souhaitez que Java 17-open soit défini par défaut (Y/n) :Ceci est important lorsque vous installez une nouvelle version d'une bibliothèque ou d'un langage, car SDKMAN ! définira cette version par défaut comme globale pour tous les terminaux de l'utilisateur actuel.
De temps en temps, SDKMAN ! doit mettre à jour les index. Au cours de cette opération, vous pouvez recevoir un message indiquant qu'il existe de nouvelles versions des outils que vous utilisez. Vous pouvez vérifier quelles sont les versions disponibles en tapant sdk ls. Pour sdk ls maven:
Versions disponibles de Maven
================================================================================
3.8.6 3.3.3
3.8.5 3.3.1
3.8.4 3.2.5
3.8.3 3.2.3
3.8.2 3.2.2
3.8.1 3.2.1
3.6.3 3.1.1
3.6.2 3.1.0
3.6.1 3.0.5
3.6.0 3.0.4
3.5.4
3.5.3
3.5.2
3.5.0
3.3.9
================================================================================
version locale
en cours d'utilisation
================================================================================Comme nous le voyons ci-dessus, Maven a une version plus récente que celle que nous utilisons. Il en va de même pour mvnd (0.8.2) et Java (19-open). Mettons tout à jour. Pour cela, il suffit d'appeler la commande install mais cette fois-ci, nous n'utilisons pas de spécificateur de version :
$ sdk install maven
$ sdk install mvnd
$ sdk install javaMais il s'est passé quelque chose d'anormal. Maven et mvnd ont des versions correctes, mais Java a une version 17.0.5-tem. C'est parce que la version la plus récente de l'outil est contrôlée par son fournisseur et non par SDKMAN ! local. Qui est ce fournisseur ? Dans SDKMAN !, un vendeur est quelqu'un qui peut publier une version. Cependant, admettons que nous ayons finalement installé 19-ouvertet nous l'avons mis par défaut, mais pour une raison ou une autre, nous avons besoin d'utiliser 17-ouvert.
Nous pouvons configurer un par défaut version d'un outil qui est globale pour tous les projets et terminaux. Mais lorsque nous avons besoin d'une version spécifique, nous avons deux possibilités. La première consiste à utiliser la fonction sdk use à chaque fois que nous voulons utiliser une version spécifique d'un outil dans le terminal courant. La seconde consiste à préparer une liste de versions dans un fichier .sdkmanrc qui est stocké avec le projet.
Alors que la première option est destinée à un usage unique, la seconde est conçue pour le travail en équipe et le partage des configurations entre les utilisateurs. équipe les membres.
SDKMAN ! est très facile à utiliser et dispose d'une riche bibliothèque d'outils, de cadres et de langages pris en charge. Il fonctionne sous Linux, MacOS et Windows. En revanche, cet outil est axé sur la JVM et nécessite l'acceptation de l'auteur en tant que fournisseur. En outre, la mécanique de .sdkmanrc est très médiocre et pourrait ralentir considérablement le processus de changement d'annuaire.
Si vous avez besoin d'utiliser de nombreux langages et outils, vous devriez jeter un coup d'œil à asdf. Cet outil se concentre sur les outils de "haut niveau". Alors que dans SDKMAN ! vous pouvez trouver de nombreux outils spécifiques à Java, comme Bpipe ou Znai, asdf offre beaucoup plus d'outils, mais pas aussi spécifiques. Bien sûr, certains de ces outils se chevauchent, par exemple Java, Tomcat ou mvnd sont disponibles dans les deux.
Lorsque vous souhaitez utiliser asdfVous devez avoir git et boucler installé. Ensuite, il vous suffit de :
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2et ajoutez ces lignes dans ~/.bashrc file:
. $HOME/.asdf/asdf.sh
. $HOME/.asdf/completions/asdf.bashVous pouvez désormais installer des plugins et des outils dans vos versions préférées.
Contrairement à SDKMAN ! asdf utilise des plugins pour gérer les outils. Ainsi, avant d'installer un outil, vous devez installer un plugin. Revenons à notre projet d'exemple et essayons de configurer l'environnement à l'aide de asadfsdf.
Tout d'abord, nous devons installer les plugins :
asdf plugin add java
asdf plugin add maven
asdf plugin add mvndNous pouvons ensuite installer nos outils :
asdf install java openjdk-17
asdf install maven 3.8.4
asdf install mvnd 0.7.1Et une fois de plus, contrairement à SDKMAN ! asdf ne change rien à notre environnement. Lorsque nous essayons d'utiliser Java, nous obtenons un message d'erreur du type :
Aucune version n'est définie pour la commande Java
Pensez à ajouter l'une des versions suivantes dans votre fichier de configuration à ~/.tool-versions
java openjdk-17Nous devons créer un fichier .tool-versions dans le répertoire personnel pour gérer les versions par défaut.
Mise à jour des versions de logiciels avec asdf est assez simple. Il suffit d'installer une nouvelle version. Comme ce processus n'affecte pas l'environnement, nous pouvons le faire à n'importe quel moment et à n'importe quel endroit du système de fichiers. Lorsque nous voulons utiliser une version spécifique d'un logiciel, nous devons créer dans le répertoire du projet un fichier .tool-versions qui pourrait être partagé entre les membres de l'équipe. N'oubliez pas que vous devez vous assurer que tous les membres de l'équipe disposent des informations suivantes asdf et des plugins installés. La liste des plugins que vous pouvez trouver ici.
asdf ne prend pas seulement en charge les langages de programmation, les cadres et les outils tels que vim ou kubernetess. Il prend également en charge les bases de données. Dans ce cas, nous pourrions installer plusieurs versions de Postgres, par exemple, mais une seule instance pourrait fonctionner. C'est parce que asdf exécute des commandes directement sur votre système d'exploitation sans aucune couche de séparation. Cela entraîne des problèmes tels que "port déjà utilisé" et des conflits de ressources.
asdf est un très bon outil si vous souhaitez travailler dans un environnement polyglotte. Il prend en charge de nombreux outils, langages et cadres. L'architecture basée sur des plugins permet de l'étendre très facilement. Cependant, certains outils présents dans la bibliothèque nécessitent un travail supplémentaire lors de l'installation afin de fournir toutes les dépendances nécessaires. asdf ne fonctionne pas sous Windows, même sous WSL.
Lorsque je parle du conflit portuaire ci-dessus, beaucoup d'entre vous connaissent la solution.
Docker pourrait nous aider dans certains cas. Je le mentionne par devoir, car cet outil est si grand et si complexe qu'il est impossible d'en parler dans un seul article.
Avec Docker, nous devrions utiliser un fichier docker-compose qui nous donne la possibilité de coordonner des environnements multi-conteneurs.
Docker nous aide à gérer des outils qui ont besoin de ressources spécifiques, comme des ports ou des fichiers. Il sépare les instances dans des conteneurs et nous donne un contrôle total sur ces derniers. Néanmoins, Docker est un outil qui introduit beaucoup de complexité dans notre environnement de travail et peut s'avérer problématique dans certains cas. L'un de ces cas d'utilisation de Docker dans un test est décrit dans l'une de nos précédentes publications. article.
Je sais que je n'ai pas décrit tous les outils qui peuvent être utilisés pour gérer les versions d'outils. Il en existe beaucoup d'autres, tels que jEnv qui pourrait remplacer SDKMAN,
ou NVM que nous pouvons utiliser pour gérer npm ou RVM pour Ruby. Je me suis concentré sur les outils que j'ai "testés sur le champ de bataille" et que je peux recommander à tout le monde.
French 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
Arabic 
Italian 
Japanese 
Korean 
Polish