Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande
Fournir le service (au client donc) est indépendant de la «tambouille» interne dev/admin pour savoir qui doit se taper le boulot. Parce qu'on peut tres bien prendre le même raisonnement, dire que le boulot de dev, c'est de fournir un code qui marche en respectant les contraintes de libs et que du coup, c'est à lui de se demerder avec la version packagé de la lib (celle qui est testé par les packageurs, dont on sait qu'elle va avoir les patchs de sécurité) plutôt que celle fraichement tagguée sur github (celle où la retro-comptabilité a été cassée sans faire expres, dont la conf par défaut à changé dont...).
La question est donc : qu'est ce qui nous coute le plus cher, qu'est ce qui est le plus pérenne. Si tous tes services sont déjà dockerisé, chaque appli tourne avec la version qu'il lui faut, effectivement, c'est simple. Sinon, ca peut etre vachement compliqué et risqué de faire tourner plein de fois la meme lib à des versions différentes.
Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)
Parfois, on peut oublier qu'il n'y a pas que l'appli sur laquelle on est en train de bosser qui tourne sur la machine, mal mesurer un effet de bord etc. Le «Je comprend pas pourquoi les tests passent pas sur la plateforme de tests, en local ils marchent très bien» ça m'est arrivé, ainsi qu'aux collégues une paire de fois.
[^] # Re: Trollons
Posté par Guillaume Rossignol . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 3.
Fournir le service (au client donc) est indépendant de la «tambouille» interne dev/admin pour savoir qui doit se taper le boulot. Parce qu'on peut tres bien prendre le même raisonnement, dire que le boulot de dev, c'est de fournir un code qui marche en respectant les contraintes de libs et que du coup, c'est à lui de se demerder avec la version packagé de la lib (celle qui est testé par les packageurs, dont on sait qu'elle va avoir les patchs de sécurité) plutôt que celle fraichement tagguée sur github (celle où la retro-comptabilité a été cassée sans faire expres, dont la conf par défaut à changé dont...).
La question est donc : qu'est ce qui nous coute le plus cher, qu'est ce qui est le plus pérenne. Si tous tes services sont déjà dockerisé, chaque appli tourne avec la version qu'il lui faut, effectivement, c'est simple. Sinon, ca peut etre vachement compliqué et risqué de faire tourner plein de fois la meme lib à des versions différentes.
Parfois, on peut oublier qu'il n'y a pas que l'appli sur laquelle on est en train de bosser qui tourne sur la machine, mal mesurer un effet de bord etc. Le «Je comprend pas pourquoi les tests passent pas sur la plateforme de tests, en local ils marchent très bien» ça m'est arrivé, ainsi qu'aux collégues une paire de fois.