Reprise du message précédent :

 
Une petite anecdote qui date de quelques années :
 
On avait en TMA une appli dont le moteur était écrit en PL/SQL, l'une des procédures sujette à beaucoup de maintenance était un programme qui déchargeait des millions de lignes dans une centaine de fichiers XML dont la concaténation et l'envoi au partenaire destinataire des données restaient à notre charge.
 
Les échanges de fichiers avec le développeur se faisait via un vilain service FTP hébergé sur notre plateforme (bon, au travers d'un VPN).
 
Le développeur de l'époque, une personne qui s'est retrouvée sur ce poste par la force des choses et qui a visiblement fait sa carrière sur des malentendus et des relations, est incapable de recetter le flux puisqu'elle ne connaît pas le Shell et qu'elle ne sait pas comment concaténer les fichiers issus de "sa" procédure. Elle me demande donc de lui mettre à dispo le script qui s'occupe de ça chez nous : je le simplifie pour qu'elle puisse l'utiliser sans se poser de question (il n'y a qu'à le lancer depuis le répertoire de déchargement des XML, sans aucun paramètre) et lui dépose sur son espace FTP.
 
Deux heures plus tard, elle me rappelle : "Je ne comprends pas ça ne marche pas votre truc, là".  
 
Mis à part un dépot dans le mauvais répertoire, je ne vois pas, alors je lui demande le code retour et le message d'erreur : elle ne sait pas, "yarien"
 
Et pour cause, voilà ce qu'elle faisait pour "lancer" mon script : elle se connectait sur le service de dépot via FileZilla et... Double cliquait en boucle sur le fichier en espérant qu'il se téléporte tout seul sur leur serveur Unix, se déplace dans le bon répertoire et s'exécute par magie    
 
Par curiosité, je lui demande d'ouvrir son dossier de téléchargement : "oulàlà c'est quoi ça ! Script.sh Script(1).sh Script(2).sh [..] Script(25).sh"  
 
Le meilleur reste pour moi la chute de l'histoire : à cause de ça (elle n'a jamais compris mes explications, à savoir transférer le script de son poste de travail vers son serveur de recette), la version n'a jamais été recettée, le traitement ordonnancé décâblé... Et jamais réinstancié puisque qu'entre temps le partenaire nous a dit d'aller nous faire voir avec notre fichier  

Voila!
Et, pour ceux qui utilisent BitBucket, j'ajouterais Confluence au package.
A+,

Clearcase, c'était ce qu'il y avait de mieux... jusqu'à l'arrivée de git.
(j'ai utilisé au cours de ma vie de dev, les fichiers .bak ( ), rcs, cvs, un proto de Sun complètement buggé (basé sur des techniques préfigurant celles de clearcase, TeamWare je crois), vss, clearcase, perforce, svn, et git).
Et (mais c'est sans doute une habitude acquise a l'age des floppies de 360k) j'ai toujours un double de mon code source sur un média externe (actuellement une clé USB de 128Go) dédiée à cela et rien d'autre (j'ai ma clé de 256Go pour le reste ).
A+,

Même cpold est mieux foutu que clearcase.

Je ne suis pas habilité sur ce projet (je l'étais avant). Je voulais récupérer des fichiers de config de tests unitaires que j'avais écrits.    
 
Sinon je passe par bitbucket, on a toute la suite atlassian.

Celles qui externalisent à 100% leurs serveurs et ne vont pas payer un serveur de plus alors qu'il y a du stockage disponible sur OneDrive qui est déjà payé par l'entreprise
Ils n'ont qu'à se débrouiller un peu ces script-bouilleurs de codes, et qu'ils ne viennent pas dire qu'il n'y a pas de client Linux pour OneDrive (ce que j'ai filé comme lien à un dév - presta en plus - qui voulait utiliser son serveur perso Git hébergé chez OVH)

ça c'est un autre sujet... le "Bac pour tous" ça n'aide pas aussi  

qd j'ai eu assez d'argent de poche (3mois sans rien dépenser ) j'ai pu me payé le cable de transfert et je suis donc passé à l'asm z80  
edit : en pascal la perf calculette sensible au nombre de ligne du code source. fallait donc optimiser tous les algo pour gagner en reactivité

 
C'était parfait (au début des années 2000) si tu avais un gros projet (plusieurs million de lignes de code C) hétéroclite (une palanquée d'OS a supporter, car à l'époque, il y avait des unix, pas un linux), et une douzaine de devs dessus.
Le seul truc de l'époque super-configurable en ce qui concerne les branches, etc. et avec un outil de merge graphique super pratique.
Mais il fallait un ingénieur système a mi-temps (au moins) pour faire marcher le bousin.
A+,
 

J'ai utilisé il y a 20 ans un truc nommé continuus, c'était assez lourdingue et affligeant.
Même SCCS ou CVS en ligne de commande était plus user friendly.

Son autre mi-temps servait a maintenir les bécanes pour builder les nightly de test, maintenir les 20+ machines dédiées aux testeurs, et aux scripts automatiques de test, maintenir la BDD d'incidents. Et maintenir les bécanes des devs (une bécane Sun, un PC et un Mac en ce qui me concernait)
A+,

En étant pessimiste GitHub et GitLab coûtent de l'ordre de 2-3‰ du salaire d'un dev (BitBucket encore moins mais faut généralement ajouter d'autres produits de la suite Atlassian donc on va l'exclure pour faire simple).

Texas Instruments en force    

Un truc qui trouait le cul à l'époque sous Clearcase c'était le diff de fichiers Word qui invoquait directement le track change    
 
 

Sur cet aspect git est juste parfait. Tu peux monter un pseudo shadow IT en hébergeant tes dépôts bruts sur les partages réseau et si l'envie te prends un jour de te mètre en règle (genre nous on a fini par basculer sur les TFS fournis par la DSI) le dépôt se transfère en deux temps trois mouvements.  
Et possibilité de cascader des dépôts via un support intermédiaire (one drive ici, clé usb dans le pire des cas) pour rester synchro sur des systèmes hétérogènes.

Oui mais tout service n'a pas un ingé à mi-temps sous la main. Quand c'est le cas, il est souvent occupé ailleurs.
 
Et comme le souligne DDT, une license est (la plupart du temps*) beaucoup moins chère qu'un employé qualifié. À plus forte raison si c'est un presta.  
 
 
* : il y a, cependant, toujours des licenses à plusieurs dizaines de milliers d'euros par an et par poste.

nope. get-childitem est un de ceux qui me fait chier si le registre n'est pas configuré, meme sous windows 10, parce qu'il pete une erreur si les noms de fichiers font plus de 260 caractères
(mais ya des commandlet qui ont l'air de fonctionner...)

celui qui passe partout, jusqu'à présent, dans mes tests, c'est... icacls.exe
ça fait un peu chier pour faire un listing de répertoire, mais des fois, j'ai pas le choix

La licence ClearCase était assez chère pour l'époque, c'est ce qui a rebuté pas mal de boites (en plus de l'infra/support nécessaire).
 
En tout cas, quand je vois mon environnement de dev actuel: outils BitBucket + Confluence + Jira + Jenkins*, et un environnement de déploiement/test de dev entièrement sous AWS, je constate qu'on a fait de sacrés progrès depuis l'époque floppy + wordstar + .bak
A+,
* Hélas, il reste encore du Snow

 
très dépendant d'atlassian tout ça
 
Bon on utilise jira aussi, bitbucket non  ( svn en interne historique, et github privé en externe pour partager avec les prestas ), et jenkins évidemment. Confluence, c'est quoi, c est pour faire de la doc ? Ah oui c'est un genre de wiki, moi j'avais fait un wiki avec mediawiki, mais ça sert pas trop ( à part moi ).
 
AWS connait pas. Amazon cloud ?

Recentrons, svp  

Confluence, c'est de la doc partagée.
On a eu pas mal de tentatives qui ont foiré dans ce domaine (le pire étant celle avec emploi généralisé de sharepoint).
Confluence le taff sans être lourd à l'emploi.  
A+,
 

Dans quel univers Sharepoint est une bonne idée ?
 
La suite Atlassian est pas mal pour l'avoir pas mal utilisé. Bien intégrée et tout.
(Bon sauf Crowd qui est un "presque-ldap" impossible à intégrer correctement)

Sharepoint cette put*** de fausse bonne idée.
 
Mis en place à l'arrache chez nous, personne de formé, surtout pas un admin, tous le monde qui peut créer ce qu'il veut dedans.  
C'est un vrai bordel, la BDD fait 700GO avec les fichiers dedans et tout .. le rêve.

 
   
Exactement la meme ici

 
C'est toujours mieux que d'avoir des disques réseaux avec
- Document_v1.docx
- Document_v1a.docx
- Document_V2a_userA_final.docx
- Document_v2_userB_draft.docx
+ un folder "archive" avec plein de brols  

tous ces geeks qui vantent chacun leurs outils de collabo génération de boite de dialogue  

 
Non pas vraiment  
 
Les dossiers c'est simple, gérer les droits finement par des groupes c'est en place et géré par l'équipe d'exploit, les users sont responsable de leur sous dossiers.
Y un outil de backup simple et rapide ..
 
C'est so '2000 mais ça marche
 

Woh woh woh… Wait a minute.
La BDD est binaire !????

L'un n’empêche pas l'autre ...
Tu peux aussi faire du caca dans Sharepoint.

tu connaissais pas Filemaker?

Dans ma boite, trois fois sur cinq, on n'avait pas les droits de lecture sur les specs mises à jour (et comme on les voyait même pas, on ne savait pas qu'il y avait eu une MAJ).
Et j'ai connu des utilisateurs qui y foutaient un zip de 70Mo en pièce jointe plusieurs fois par mois, histoire d'avoir un snapshot des données (pas sous git) à l'instant t    
A+,

 
Perdre un client pour ça    
 
Aucune conséquence pour elle j'imagine ?

Git-svn est ton ami

+1
Dans ce cas, un Undo/Redo pour voir quelle était la modif non voulue
C'est aussi ça que je n'aime pas avec les sauvegardes auto : parfois on ne veut pas sauver les modifs...

 
J'ai pas dit le contraire    
Par contre en 2014 qu'en t'es "leader européen" dans

Le mettre en place sur différend projet comme si c'était une révolution, faire des formations dessus etc, c'est dommage  

Donc vous devriez être à la pointe de la technologie.  

Si tu voyais comment est gérée l'informatique, les réseaux, les outils numériques en général, dans le secteur aéronautique...

C'est vrai quoi. Parlons d'outils de ticketing pour changer rester sur le sujet.

Les cordonniers ....  

 On fabrique des ordinateurs dans l'aéronautique ?