Reprise du message précédent :

 
 
donc en fait tu veux corriger gratuitement leur version et ils refusent ?  
 
 

a la base docker c pour les dev web qui sont pas foutus de faire une procédure reproductible pour setuper un environnemement de dev  

C'est admettre qu'il y a une erreur dans leur code, ca doit pas leur plaire

Bah en fait ils sont en plein dans leurs contractions : ils veulent pouvoir récupérer un patch facilement depuis une pull request GitHub alors que leur propre code est pas sur GitHub (uniquement dans SRPM livré à chaque release de XenServer, donc impossible de contribuer). Le beurre et l'argent du beurre. Mais j'ai appris de source interne que ce mec là nous aime pas (le plus fort c'est qu'il ne bosse même plus dans l'équipe XenServer, mais c'est la mémoire vivante de ce code donc on lui demande parfois des modifs)

Tant pis, on corrigera de notre côté

 
Payer la grösse dîme, AD cloud, plus de problèmes.

 
C'est assez WTF ça chez les merdes javascript. Sur NuGet c'est impossible d'effacer un paquet une fois qu'il est publié.
 
Heureusement encore une fois MS nous sauve si on paye la dìme pour garder toutes les dépendances dans son cache privé sur Azure DevOps.

C'est superflux tout ça, Linux c'est secure.

NPM a mis en place une protection pour corriger ce problème.
 
Le truc le plus débile dans l'histoire c'est que c'était simplement package qui contenait 1 ligne de code pour faire un padleft...
Pour ce genre de merdes j'ai toujours une classe "Utils" ou un dosseir Utils dans mon application.
Et idem pour le formatage de dates, j'utilise toujours une petite fonction ça m'évite les gros pavés inutiles qui gère la pluie et le beau temps.

Oui.
Après cet incident.

ou aussi faire en sorte de faire cohabiter différentes versions d'exécutables et / ou de variables d'environnements sur une même machine

Clair qu'il faut au moins Docker pour ça.

nan un chroot et un script bien fait ça fait le job au pire
 
mais pour un dev, trop compliqué de faire une procédure.  
donc autant foutre un gros blob.  
 
 
aujourd'hui, ton smarphone lance un navigateur qui fait tourner un javascript dans une VM pour faire du REST/SOAP, en face t'as une page JSP dans une JVM dans un docker dans une vm sur un hyperviseur dans le cloud
 
T'as dépensé 5kW d'énergie et 2500 lignes de code pour faire la même chose quasiment qu'un AS400 40 ans plus tot  

Sachant qu'il est devenu de plus en plus complexe de gérer les dépendances entre logiciels ainsi que les versions installées, oui docker est une solution. C'est vrai qu'il remet le SI a sa juste place d'utilisateurs face aux concepteurs et que ça ne leur plait pas (dans leur sentiment de supériorité   ). En tous cas, plus de problème de prérequis ingérable qui font trainer les projets de par la mauvaise volonté du SI. Si ça deconne c'est de la faute des Devs mais si ça fonctionne c'est aussi grâce aux Dev  

 
FYP

 
Je te l'accorde  

 
Inventer un problème pour pouvoir fournir une solution, y'a bon Business Plan
(Dit aussi "principe du legislateur français" )

 
C'est juste que quand tu developpe une interface AS400 ça te prend 1heure mais maintenant tu as 500 personnes qui auront un avis différent sur ton écran de saisie, les designers, les chefs de projets, ton direccteur, tes clients... ils ont tous vu LE BOUTONALAMODE qu'il te faudra obligatoirement implementer pour être moderne. Idem pour tout le reste, il te faut gérer celui qui a du DB2; celui qui a du SQL, celui qui à du Oracle, du MySql, celui sous windows 2010, celui sous 2016, etc... Au final il t'est impossible de developper ton application sans utiliser des dixaines de frameworks qui ont tous leurs prerequis, leurs incompatibilités, leurs problemes, leurs failles. Lorsque tu as enfin quelque chose qui tourne -> Docker. Ton logiciel sera quasiment impossible à installer autrement (ou en y passant des jours pour qu'il fonctionne à peu près). Bienvenue dans le monde moderne  

Oula.
Dredi puissance 10 là

Ah bah oui, que les devs sont bêtes, en voilà une solution robuste et facile à maintenir.
 
Nix est intéressant dans les contextes où la conteneurisation n'a pas de sens.
Mais sinon je vois pas trop le problème, ça arrange largement mes admins de ne s'occuper que de l'orchestrateur et laisser le déploiement de toute la couche applicative aux devs.

 
Tu m'étonnes, chacun sa merde

Mais quel admin sain d'esprit voudrait foutre les mains dans cette merde franchement

T'as l'air de t'y connaître en tout cas

Ceux qui veulent garder leur boulot et éviter de se faire remplacer par quelques fichiers YAML, au hasard.

Quand on voit le niveau général en informatique des dev actuels, les gars qui font de l'infra pas trop bêtement ont encore de beaux jours devant eux.

 
Ca va les chevilles ?

Surtout que j'aimerais bien connaître les critères pour évaluer un "mauvais" dev ? Sa boîte embauche peut-être que des mauvais juste pour l'emmerder
Des mauvais dev j'en croise toujours de temps en temps, des admins sys j'en croise de moins en moins tout court par contre

C'est exactement pour ça que sur le terrain (dans 90%+ des cas), ya les admin qui font de la virtu pour fournir un couche de base "gérable" tout en laissant les devs faire leur popote

Comme ça tu t'embêtes pas avec la maintenance sur les serveurs. Et ça t'empêche pas de fournir des services "modernes" par dessus (Terraform, Packer etc.)

edit : je parle d'une clientèle qui garde ce savoir-faire en interne (ou alors d'hébergeurs), et pour eux, garder la virtu c'est la vie Le client final n'est pas dérangé en cas de maintenance, car tu migres tes VMs etc. Et ça permet de faire pas mal de trucs cool aussi, avec du bare metal c'est plus compliqué.

En lisant ça j'ai l'impression de revenir aux discours de vmware il y a 15 ans

 
Y'a la bon dév et le mauvais dév  

 
Ba non c'est la réalité.
 
Ils font du dev, bouffent du json, consomment de l'api et montent des Machines Learning.
 
par contre, "site unreachable" et ils sont en PLS.
 
Savoir sur quoi ça tourne, les problèmes liés (de mémoire, de perf, d'écriture sur un disque donc de locks, ...), 0.
Comprendre les différences de problèmes entre l'ip, le dns et le certificat pour leurs applis web.
Savoir écrire des images dockers statefull qui démarrent correctement.
...
 
Ancien dev passé par l'infogérance avant de devenir archi, les échanges sont pas toujours simples.
 
Un ops qui bosse sur la partie infra et qui n'est pas trop con/braqué continuera à bosser sans problèmes.
L'app est dans un docker ? ouais, on a géré le packaging pour la livraison.
Faut encore gérer le monitoring, la gestion des données/backup, la résilience de l'application, la non-régression dans les livraisons, la gestion des mdps et des secrets, ...
 
Et pour discuter avec les devs, leur macher le travail côté images docker, gestion des logs, du monitoring, ... ils prennent.
 
Il y a encore ENORMEMENT de taf côté ops, vraiment.

 
qu'est-ce que tu veux dire par là ?

Qu'il est vieux

Tu m'étonnes
Et je parle même pas encore de la partie DBA  

Tu demandes à mon frère, il fait de la revue d'architecture & support L4 quand il n'est pas sur des trucs classés. Autant dire que sur ces missions, il pleure presque tous les jours.

Le problème vient de deux choses en moyenne d'après la quantitonne de couinements qu'il pousse pendant des heures :
- Conception foireuse ou inutilement complexe à cause manque de réflexion de haut niveau sur l'archi.
- TU bâclés ou tout simplement... pas réalisés.

En gros le mauvais dev, il code mais juste son bout de truc ou de fonction sans voir plus loin. Le bon dev il code mais en réfléchissant et anticipant sur l’évolution/intégration/régressions de son bout de code à l'ensemble.

Il faut à priori un gros paquet d’expérience et d'années pour passer du premier au second stade, même chez les bons.

Il y a un problème de culture aussi.

Quand c'est pas la direction qui a fait le choix foireux d'économiser sur tout le reste.

en-US non?

Comme l'a dit nucl3arfl0 il faut juste que ça fasse partie de la culture de la boîte.

Tu penses que les wagons de juniors engagés par Amazon mettent des années avant de réfléchir à tout ça?
Non car ils assurent tout le cycle de vie de leur code, astreintes comprises. Et personne n'a envie de se faire réveiller à 3h du mat car un bout de son code (ou pire, d'un collègue) vient de péter et faire foirer des ventes à l'autre bout du globe.

Alors oui c'est un cas extrême, mais même dans mon premier job où la culture était très old-school (waterfall, pas de devops, ...), tant qu'on livrait pas un truc bien intégré et qui tourne, la responsabilité était à 100% sur mon équipe, et par conséquent surtout sur les juniors (de nouveau boîte old-school, plus t'étais senior moins tu codais). C'est seulement une fois l'app testée par une équipe QA externe puis mise en production de manière satisfaisante pour les utilisateurs, et après 2-3 mois, qu'on pouvait s'en débarrasser.

L'expérience ça te permet de faire moins de conneries, de réaliser tes conneries plus vites, et de faire les choses correctement en moins d'itération.
Mais le processus ne change pas énormément.

Et comme on dit, dix fois un an d'expérience ce n'est pas pareil que dix ans d'expérience.
Si tu paies des cacahuètes et engages des devs pour pisser du code sur un nouveau projet tous les 3 mois, ils vont pas devenirs "bons" pour autant, peu importe les années d'expérience.

+1 DDT
Ma première expérience était dans le logiciel spatial, avec un degré de contrôle/vérification énorme.
Leur adage principal "chez les autres domaines, c'est 70% de dev, 30% de test, ici, c'est 30% de dev, 70% de test"
 
Tout était documenté, spécifié, testé complètement avec application de la chaine au total.
 
Tiens, je suis tombé dessus chez 9gag
https://9gag.com/gag/aqnV97p

Chez nous côté infra on est souvent obligé de mettre en place des scripts palliatifs ou de monter des archis tordues pour que les applis produites par nos chers dev tournent à peu près correctement. Quand on nous livre une appli moisie, 4 fois sur 5 les managers font le forcing pour que ça aille quand même en prod car il y a des fonctionnalités urgemment attendues.
En fait on devine même assez souvent qu'on va droit dans le mur avant que l'appli arrive en prod...mais on insiste pour que ça passe au forceps... car c'est urgent et qu'on a déjà engagé des moyens dessus. Personne pour dire stop on fait de la merde, on reprend de zéro ou on fait autrement. Et c'est comme ça qu'on se retrouve avec des verrues compliqué à gérer en exploitation.