Je suis pas sur de comprendre ou tu veux en venir. Une instance Jenkins, c’est grosso modo une heure à mettre en place, avec discovery des pull requests, ping back à GitHub etc. Et demander de ne pas builder/packager/déployer depuis le laptop de jean rené, c’est pas le bout du monde quand même?
De mon expérience, très limitée donc peut-être pas représentative, dans une petite ou moyenne entreprise avec un service informatique réduit, tu peux réussir à imposer des choses.
Dans une structure avec environ 250 employé⋅es pour le seul service informatique à lui tout seul, dont l’informatique n’est pas le métier premier, et qui est le fruit de multiples fusions successives depuis plus de vingt ans, oui, tu peux demander une VM et y coller un Jenkins, le configurer dans les règles de l’art. Au final il y a une possibilité que tout ton service (et si tu es technique, TON service, c’est pas 50 gus, plutôt une dizaine grand max...) adhère au concept, mais bien plus de chance que tu finisses à être seul à l’utiliser.
Nous avons des développeurs, nous avons une CI, Jenkins en fait d’ailleurs partie, mais je pense que tu n’as pas conscience de ce que ça représente comme architecture logicielle et procédures associées. Je ne peux malheureusement pas t’en dire davantage, ce ne serait pas professionnel de ma part, mais franchement tant mieux ! ^^
et pas besoin de jq à la truelle
Pourquoi « à la truelle » ? Ce sera probablement plus long à écrire, moins facile à lire mais c’est loin d‘être un inconvénient franchement insurmontable.
genre des tableaux, des maps, et même des nombres.
Des tableaux (liste ou hash) tu as ça aussi en bash, tu as des nameref, des pipes nommés, des descripteurs de fichier, la programmation multi-thread est native (&, wait), tout comme l’usage de signaux (kill, trap)... Je t’accorde que c’est un paradigme assez particulier, et clairement pas des plus intuitif, mais ça ne fait vraiment pas de bash un outil obsolète pour autant. Je pourrais te citer encore d’autres avantages mais il se fait tard.
Et pour les inconvénients, le dernier piège dans lequel je suis tombé (et dans lequel on ne tombe qu’une fois...) et qui m’a fait perdre pas mal de temps, c’était il y a déjà un moment, et ça concerne les fonctionnalités natives pour l’arithmétique de bash, qui sont je te l’accorde une source de critiques justifiées : le fait que de manière absolument contre intuitive, un nombre entier commençant par un 0 est interprété comme étant de l’octal. Dans mon cas je me retrouvait donc avec un bug survenant seulement pendant 2 semaines sur les 52 que compte une année... l’exemple typique du bug qui peut faire exploser en vol un traitement au terme de plusieurs mois d’exécution sans faute, et qui peut facilement être source d’une hécatombe capillaire certaine si on ne l’a jamais rencontré auparavant. Depuis je considère volontiers qu’utiliser bc (ou dc) systématiquement et réserver le recours à l’arithmétique native lors d’une éventuelle phase d’optimisation du code est une sage décision. Cela permet en outre de disposer d’une précision arbitraire automatiquement sans avoir à prévoir l’utilisation d’un type différent d’entier.
[^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 3. Dernière modification le 21 novembre 2023 à 23:22.
De mon expérience, très limitée donc peut-être pas représentative, dans une petite ou moyenne entreprise avec un service informatique réduit, tu peux réussir à imposer des choses.
Dans une structure avec environ 250 employé⋅es pour le seul service informatique à lui tout seul, dont l’informatique n’est pas le métier premier, et qui est le fruit de multiples fusions successives depuis plus de vingt ans, oui, tu peux demander une VM et y coller un Jenkins, le configurer dans les règles de l’art. Au final il y a une possibilité que tout ton service (et si tu es technique, TON service, c’est pas 50 gus, plutôt une dizaine grand max...) adhère au concept, mais bien plus de chance que tu finisses à être seul à l’utiliser.
Nous avons des développeurs, nous avons une CI, Jenkins en fait d’ailleurs partie, mais je pense que tu n’as pas conscience de ce que ça représente comme architecture logicielle et procédures associées. Je ne peux malheureusement pas t’en dire davantage, ce ne serait pas professionnel de ma part, mais franchement tant mieux ! ^^
Pourquoi « à la truelle » ? Ce sera probablement plus long à écrire, moins facile à lire mais c’est loin d‘être un inconvénient franchement insurmontable.
Des tableaux (liste ou hash) tu as ça aussi en bash, tu as des nameref, des pipes nommés, des descripteurs de fichier, la programmation multi-thread est native (&, wait), tout comme l’usage de signaux (kill, trap)... Je t’accorde que c’est un paradigme assez particulier, et clairement pas des plus intuitif, mais ça ne fait vraiment pas de bash un outil obsolète pour autant. Je pourrais te citer encore d’autres avantages mais il se fait tard.
Et pour les inconvénients, le dernier piège dans lequel je suis tombé (et dans lequel on ne tombe qu’une fois...) et qui m’a fait perdre pas mal de temps, c’était il y a déjà un moment, et ça concerne les fonctionnalités natives pour l’arithmétique de bash, qui sont je te l’accorde une source de critiques justifiées : le fait que de manière absolument contre intuitive, un nombre entier commençant par un 0 est interprété comme étant de l’octal. Dans mon cas je me retrouvait donc avec un bug survenant seulement pendant 2 semaines sur les 52 que compte une année... l’exemple typique du bug qui peut faire exploser en vol un traitement au terme de plusieurs mois d’exécution sans faute, et qui peut facilement être source d’une hécatombe capillaire certaine si on ne l’a jamais rencontré auparavant. Depuis je considère volontiers qu’utiliser bc (ou dc) systématiquement et réserver le recours à l’arithmétique native lors d’une éventuelle phase d’optimisation du code est une sage décision. Cela permet en outre de disposer d’une précision arbitraire automatiquement sans avoir à prévoir l’utilisation d’un type différent d’entier.