Introduction

Quand on gère une équipe de développement, indépendamment de la problématique humaine, se pose la problématique des outils et des environnements de travail.

Selon la stack technique du projet, Java, Python, TS, .NET, … les outils de développements (les IDE’s) ne sont pas les mêmes. En outre, si notre projet a besoin de processus tiers comme une base de données, un annuaire, un serveur JMS, un Keycloak, … il faut prévoir son installation et sa mise à disposition pour les équipes de développement.

Vient s’ajouter à cette complexité de mise en place les problématiques liées aux versioning des éléments précédents, la version du Java, du NPM, du .NET core, de l’IDE, de la base de données …

L’historique

Dans un lointain passé, chaque développeur installait l’ensemble de ses outils et processus tiers sur son ordinateur de travail en local. Nonobstant les problèmes lors de ses installations se posait assez rapidement le problème de configuration et de version de ses outils. En effet, si le projet se fait sur une version Java 17 avec un PostgreSQL 14.1 chacun des développeurs devaient s’astreindre à utiliser ses versions et à ne pas faire usage d’autres versions pour ce projet sous peine de se retrouver avec des incohérences entre développeurs et des problématiques de chargement de données.

Mais que doit-on faire lorsqu’une version change ? ou plus classiquement comment faire pour gérer les développeurs qui travaillent sur plusieurs projets avec des stacks techniques très différentes.

A cette époque, plusieurs solutions existaient :

1. Chaque développeur installait tout sur sa machine de travail et le plus souvent il avait 6 versions de Java, 4 versions de postgreSQL, 3 versions de NPM …
2. Une machine virtuelle était réalisée par une équipe technique spécialisée. On faisait usage de logiciels de virtualisation tels que VMWare ou VirtualBox. Il fallait réaliser une VM par stack technique et très souvent une par projet. Les machines virtuelles étaient ensuite laissées à disposition des développeurs qui pouvaient les lancer sur leur machine de travails.
3. Une partition virtuelle (VHD/VHDX) était réalisée par un techlead. Il installait tous les outils/programmes nécessaires sur cette partition. Elles étaient ensuite laissées à disposition des développeurs qui pouvaient les utiliser sur leurs machines de travail (Windows uniquement dans ce cas-là).

Malheureusement, toutes ses solutions étaient trop contraignantes et chronophage à gérer dès qu’un changement survenait. En effet, si l’on image le cas simple de changement de version d’une base de données, il fallait

1. Dans notre cas 1, que chaque développeur installe la nouvelle version sur sa machine et réalise les changements appropriés de configurations dans leur code. Il ne fallait pas pour autant désinstaller la version précédente afin de pouvoir gérer les corrections d’anomalies sur les versions antérieures du projet.
2. Dans notre cas 2 et 3, que l’équipe technique réalise une nouvelle VM (ou VHD/X) et la redistribue à chaque développeur

De nos jours

Ses solutions sont toujours utilisables à ce jour, mais il est fortement conseillé de passer à une autre approche plus souple et plus efficace et scalable.

Depuis une dizaine d’années maintenant, la virtualisation s’est vue transformer/remplacer par la conteneurisation.

La différence est simple :

• Dans une VM : on doit tout installer, l’OS, les utilisateurs, les droits, la sécurité, les processus, … Cela donne des fichiers de plusieurs giga octet. Chaque VM qui se lance consomme beaucoup de ressource mémoire car chaque VM lance son propre OS.

• Dans un conteneur : on ne doit installer que le processus qui nous intéresse. Il sera donc beaucoup plus léger qu’une VM, de l’ordre de 10x plus léger (il dépasse rarement le giga octet). Contrairement aux VMs, l’OS qui fait tourner les conteneurs n’est lancé qu’une seule fois, la consommation mémoire est donc bien plus faible que pour les VMs.

Pour notre problématique de développement, les conteneurs vont remplacer nos solutions précédentes. Idéalement, il nous faudra utiliser un conteneur par processus nécessaire au projet.

Si l’on prend un projet en stack Java+Angular+PostgreSQL cela nous donne au moins trois conteneurs.

En 2023 le développeur aura besoin d’installer son IDE (voir ses IDEs), il lui faudra aussi installer un outil pour gérer les conteneurs (par exemple Docker Desktop) et cela sera suffisant. En aucun cas, il ne devra installer PostgreSQL ou tout autre processus nécessaire au projet.

L’équipe technique qui avait la charge de réaliser les VMs va maintenant s’occuper de réaliser des fichiers de configurations qui vont décrire les différents processus nécessaires aux développeurs ainsi que leurs configurations. On ne parle plus ici de réaliser des VMs de plusieurs gigas octet, mais de simples fichiers de configurations de quelques kilo octet.

Exemple : voici un bout de fichier, docker-compose.yml, qui décrit la configuration nécessaire au lancement d’un PostgreSQL :

Sans rentrer trop dans le détail, notez à la ligne 14 : on indique la version de PostgreSQL que l’on souhaite lancer. Sur les lignes 20 à 23 on indique les informations d’accès à notre base de données. Sur la ligne 25 on indique le port réseau qui sera utilisé pour atteindre notre base de données de l’extérieur du conteneur. Sur la dernière partie, on indique la gestion des volumes, ou comment gérer / sauvegarder nos fichiers associés au conteneur.

On donne ses fichiers aux équipes de développement, chaque développeur peut maintenant lancer cette configuration qui va :

1. Télécharger d’Internet les différents conteneurs dans leurs versions spécifiés
2. Construire chaque conteneur avec les informations spécifiées et les mettre à disposition du développeur

Via cette approche :

1. Travailler sur plusieurs projets est simple, car chaque projet a toute sa configuration technique décrite dans un fichier. Passer d’un projet à l’autre se résume à lancer la configuration associée au projet.
2. Changer une version d’un processus devient très simple, il suffit de modifier le fichier de configuration et de le propager aux équipes.

Axes d’améliorations

L’approche par conteneurs a énormément d’avantages, on peut citer entre autres :

1. Simplicité de mise en place
2. Simplicité de gestion du versioning
3. Souplesse dans les migrations techniques
4. Meilleure consommation des ressources mémoire / processeurs / espace disque
5. Possibilité de lancer ses conteneurs où l’on veut, sur sa machine ou dans le cloud
6. La configuration réalisée pour les conteneurs de développement peut servir de base pour la réalisation des configurations de pré exploitation et/ou de production.

Mais il lui reste quelques inconvénients :

1. Il faut tout de même écrire le/les fichiers de configurations. Sur un projet complexe, cela peut prendre 2 à 5 jours hommes
2. Dans le cas de projets très complexes, il faut parfois fabriquer le conteneur dans sa totalité. Le temps de travail associé à cette tâche sera très légèrement plus faible que celui pour la réalisation d’une VM, mais il reste fastidieux.
3. Malheureusement, pour le moment, il n’y a pas encore de conteneurs officiels pour les IDE’s

Ce dernier point est à mes yeux le plus problématique, en effet, le développeur doit toujours installer son / ses IDEs. Si je reprends l’exemple de ma stack technique, chaque développeur devra tout de même installer une version de Java sur son ordinateur, puis son IDE (Eclipse ou IntelIJ) et souvent un Visual Studio Code pour la partie front.

Conclusion

Le temps où l’on pourra intégrer un nouveau développeur en lui donnant juste un petit fichier de configuration à lancer n’est pas encore là, mais il se rapproche à grands pas.

Rétrospectivement, travailler aujourd’hui en tant que développeur via l’utilisation de conteneurs reste très agréable et permet une réelle homogénéité entre environnement de développement et d’éviter les problèmes liés aux changements de versions sur des outils comme NPM par exemple. Pour moi, en tout cas, c’est devenu totalement indispensable.

A noter que certains éditeurs logiciels, comme Jetbrain ou AWS via Cloud9, propose aussi des solutions full cloud ou tout, y compris et surtout l’IDE, est conteneurisé directement par eux. Si vous souhaitez partir sur ce type de solution, faites attention au ROI global ainsi qu’aux habitudes des développeurs souvent très attachés à leur IDE.

Depuis quelques années déjà, les Java’istes ont la possibilité via le framework java.testcontainers.org de piloter des conteneurs directement via leur code sans passer par la case fichier de configuration. Dans sa toute dernière version de 2023, le framework Spring Boot intègre cette fonctionnalité et la complète permettant aux développeurs de piloter les différents conteneurs et leurs configurations directement via le code et les mécaniques de profiles Spring Boot.

En espérant avoir convaincu les entreprises qui ne font pas encore usage de cette approche de s’y intéresser dans l’objectif de simplifier et d’homogénéiser leurs processus de développement.