Depuis que je travaille dans l'entreprise où je suis actuellement(une SSII lilloise), j'ai appris ce que c'était que l'industrialisation.
Le déploiement continue.
L'intégration continue.
Les tests automatisés.

Et j'en passe.

Mais il y a une autre façon, selon moi, d'industrialiser son travail, et je vais en parler via un exemple.

Beaucoup d'entreprises utilisent Git, un logiciel de versioning (grosso-modo, un logiciel de partage de travail et de projet), et c'est sur ce point que je focalise mon exemple, même s'il peut s'appliquer ailleurs.

Beaucoup de mes collègues utilisent des logiciels client Git, tel Ungit ou SourceTree.
Pour situer un peu le contexte, nous sommes en train de développer une application qui nécessite plusieurs dépendances/packages, gérée par projet. On se retrouve donc avec 6 ou 7 projets (NB: pour créer 1 seule application finale). Sur ce point déjà, je suis peu d'accord, mais bref, je ne suis pas décisionnaire de l'architecture du projet.

Tous les matins, les développeurs tirent (= pull) les projets poussés (= push) la veille au soir par leurs collègues.
On se retrouve donc à:

  1. ouvrir ce logiciel.
  2. se balader entre les branches du projet
  3. tirer les modifications du projet.
  4. changer de projet.
  5. Attendre que le logiciel finisse sa tâche (qui est souvent exécutée + lentement qu'une commande).
  6. Attendre que le logiciel ait fini de planter (ce qui peut-être réellement le cas avec + d'une centaine de commits en attente ou encore un ajout de plusieurs centaines de fichiers à pousser).
  7. Attendre que Windows ait fini de planter (bon, là c'est du troll)
  8. Recommencer pour chaque projet/chaque branche.

C'est très laborieux, dans le cas de plusieurs projets.
Maintenant, factorisons un pull via une commande, que l'on place dans un alias, dans le fichier .bashrc d'une console (Git Bash par exemple):

alias tire='git pull'

On continue de la même façon:
- avec un commit/push:

alias pousse='git add . && git add --all && git commit && git pull && git push'

(car il faut ajouter les fichiers avant un commit).

 alias tireTout ='cd projet1/ && tire && cd ../projet2/ && tire && cd ../projet3/ && tire && cd ..'

(et on continue en chainant tous les projets et les éventuelles branches).

Voilà en quoi un développeur est bon: à sa capacité de factoriser et industrialiser son travail correctement, pour éviter les tâches répétitives.
Je n'ai rien contre les logiciels-client de versioning, mais selon moi ils sont inutiles (sauf peut-être pour visualiser le Workflow d'un projet. Ils ne font pas gagner de temps, bien au contraire, et tout (bon) développeur ne devrait utiliser que ça (on laisse Source Tree aux mauvais, ok ?).

En réalisant des scripts du même genre, en chaînant mes tâches, j'ai réussi à factoriser beaucoup de mes tâches. Je n'hésiterais pas à donner une suite à cet article, avec un autre exemple (les emails?).

Et dire que l'on avait trouvé ça exeptionnel, le développeur qui avait automatisé presque toutes ses tâches. Moi j'ai trouvé ça normal.