Ça marche chez moi
Tout responsable d’équipe de développement ou participant à une réunion production/développeur a été confronté au cas du logiciel fonctionnant sur le poste du développeur et pas ailleurs. Le développeur assure de bonne fois que ça marche chez lui et en production l’utilisateur constate le contraire. Les causes d’une telle situation sont entre autres les jeux d’essais et la configuration du poste du développeur.
Mais ça marche chez moi
Dans ce dernier cas la solution est l’intégration continue qui s’assure que le logiciel se construit sur une machine vierge de tout paramétrage qui ne serait pas inclus dans le projet lui-même.
Docker
L’utilisation de docker pour empaqueter le logiciel nous assure de son côté que toute la configuration est portable. En réalité la configuration est faite une fois pour toute et embarquée dans l’image. J’entends par configuration la plomberie de paramétrage des composants et la configuration système.
Il est tentant alors pour le développeur de produire une image comme livrable. Cela pose hélas des problèmes majeurs.
Tout d’abord le poste du developpeur devient le référentiel de construction. Or le developpeur sous pression des délais utilise une méthode qui a fait ses preuves dite » Larache ». Si bien que la configuration complète qui fait tomber en marche la construction n’est pas connue. Il faudrait donc pour bien faire également fournir le poste du développeur comme source du projet !
Docker un simple outil de construction
L’utilisation de docker comme commande de construction ne dédouane pas de passer par l’intégration continue afin se s’assurer de la
Répetablité de la construction
Par ailleurs comme le test d’execution a été fait sur le poste du developpeur, il y également le biais que l’exécution tire partie d’une spécificité du poste du développeur. En effet c’est la même installation de docker qui a fait la construction qui va faire l’exécution sur le poste du developpeur.
Ainsi une même image construite en dehors de l’intégration continue ne fonctionnera peut-être pas ailleurs que sur le poste du développeur !
Integration continue un prérequis
L’integration continue est un garant de la qualité du logiciel en assurant la répetablité de la construction par la seule l’utilisation des sources obligeant ainsi à décrire explicitement toute la configuration permettant de faire cette construction.
Avec GitLab cela est poussé à l’extrême car GitLab encourage l’utilisation docker pour la construction: la commande de construction est elle-même conteneurisée ce qui assure que la configuration de docker est explicitement décrite. La construction est ainsi répétable.
Une erreur est de croire que docker permet de se passer de l’IC. Docker n’est qu’un outils de construction au même titre que maven. Cependant la prise en compte de l’IC dans le processus de création du logiciel se heurte plus à l’acceptation d’une méthodologie qu’autre chose.
Aussi le syndrôme du développeur ca marche chez moi traduit plutôt le mode de développement solitaire où les sources ne sont pas partagées (absence Git commun).
Une autre erreur est je crois de confondre DevOps avec le développement en production. Dans une informatique non indusrielle le developpeur a le pouvoir de modifier directement en production. Poste du developpeur ou poste de production c’est la même chose. Dans une informatique industrialisée ce n’est pas possible. Dans ce cas il faut faire un lien entre le poste du développeur et la machine de production.
L’intégration continue est ce lien !
Du bon usage de l’IC
Ce qui n’est pas sous IC n’existe pas
Je crois que tout développement qui a pour vocation a devenir indistriel, doit commencer par l’IC. Si le développement est purement un POC local, la mise en place de l’IC est un surcoût qui ne se justifie pas.
En revanche si le projet a vocation à entrer dans un processus industriel il faut prendre le temps de mettre en place l’IC avant tout développement. Il y a pour cela les raisons suivantes:
- Empêcher le source de s’appuyer sur des spécificités du poste du développeur
- Empêcher le processus de construction et d’exécution de s’appuyer des spécificités du poste du développement
- Empêcher l’amalgame des sources ayant des objectifs différents et permettre une structuration correcte du projet dès le départ
Ce dernier point mérite une attention particulière car si la mise sous IC et la modularisation du projet intervient tardivement, le travail de séparation peut être difficile car l’imbrication de la construction a des effets de bord qui font tomber en marche mais qui ne passent pas l’IC. Cela freine l’adoption de l’IC continue auprès des équipes de développement qui verront surtout le surcoût de refactoring du projet pour l’intégrer à l’IC.
Conclusion
L’intégration continue et son évolution en déploiement continue sont des bonnes pratiques dont la pertinence n’est pas à démontrer. Leur mise en place doit être un prérequis avant tout développement.