• Aller au contenu
  • Aller au menu
  • Aller à la recherche

CPU ⬜ Carré Petit Utile

CPU

Carré, Petit, Utile : Le programme radio des gens du numérique.
Tous les Jeudi à 11h sur Radio <FMR>

  • Programmes
  • Interviewes
  • Chroniques
  • Chercher
  • Suivez-nous !
  • CPU
  • ⬜
  • Chroniques
  • ›
  • Enfant du futur immédiat
  • ›
  • Bonjour à toi, Enfant du Futur Immédiat : Tu tires ou tu pousses ?
  • ← précédent
  • ⬜
  • suivant →

Bonjour à toi, Enfant du Futur Immédiat : Tu tires ou tu pousses ?

vendredi 22 juin 2018. Chroniques › Enfant du futur immédiat

  • communauté
  • développement
  • emploi
  • humour
  • logiciel
  • organisation
  • protocole
  • serveur

Extrait de l'émission CPU release Ex0087 : Gestion de versions de source.

Bonjour à toi, Enfant du Futur Immédiat, toi qui ne sait plus pourquoi tu as raturé ce sgouigouigoui la semaine dernière sur ton devoir de dessin.

Le principe du travail en équipe est immuable : c'est toujours la faute d'un autre. C'lui qui a cassé toute la prod, c'est surement Donald, Angela ou Emmanuel. Seulement on se retrouve vite dans une situation de délation, et un licenciement pour faute grave sans preuve peut vite conduire aux prud'hommes. La gestion de version de code source en a apporté une solution socialement acceptable.

Mais je vais un peu trop vite ! Il faut d'abord que je t'explique ce qu'est que la gestion de version de code source... ou plutôt comment faisait-on avant.

D'habitude, quand on enregistre un fichier texte, donc un code source, on écrase toujours l'ancienne version. Alors quand on a un gros projet, on faisait régulièrement des copies du répertoire de travail avec la date de copie. Et parfois dedans, des fichiers étaient des copies précédentes d'autres fichiers avec en extension .backup, .fonctionnel, .corrigé, .backup2… Si on voulait retrouver le moment où une fonction n'a plus marché, et donc le code source qui était encore fonctionnel, c'était la misère.

Autre problème, quand on était plusieurs à modifier des fichiers sur un même serveur, on se marchait souvent sur les pieds, ta sauvegarde écrasant la modification du collègue à l'étage en dessous.

Bref, c'était l'horreur

Et puis sont arrivés les premiers logiciels pour gérer les versions de code source. C'était dans les années 1970s et surtout en informatique industrielle. On commença à les voir disponibles pour PC à la fin des années 1990s.

C'était une révolution, mais elle demandait des contraintes pour la cause !
Au lieu de sauvegarder directement sa modification d'un coup assuré de touche F2, on devait prendre le temps d'écrire la raison des modifications. Et aussi de travailler avec un serveur central, un dépôt du code source, qui arbitre les fichiers du projets et comment chacun peut travailler dessus.
Tu tires depuis le dépôt, t'édites ta modification, tu commites la raison de ta modification, et tu pousses vers le dépôt.

Mais pas mal de gens se braquaient devant la nouveauté, maugréant contre la divinité du micromanagement adulée par la Direction, alors que le système de version était poussée par quelques développeurs au même niveau que les râleurs pour d'autres raisons.

Le premier effet fut de détecter les conflits quand plusieurs personnes éditaient en même temps le même fichier. Il faut alors décider quelle modification était à garder. Une fois que les conflits furent arbitrés et donc résolus, on pouvait commencer à réfléchir différemment sur les projets conséquents : Plutôt que de travailler dans un seul espace temps, on imaginait de bifurquer dans le continuum et à causer d'arborescence et de branches. Donc une branche correspond à une évolution espérée… C'est à dire qu'on pouvait bifurquer le projet, et espérer plus tard refusionner deux branches vers la branche principale, celle qui donne le produit fini.

C'était la théorie.
J'ai vu des projets qui avaient plus de 20 branches, sur lequel on picorait des commits, on répliquait des modifications à gauche à droite, qu'on appliquait anarchiquement. Une horreur.

La bonne manière d'utiliser les versions veut qu'on réfléchisse en terme de branche de production, en branche de préproduction, en tickets, en branche d'évolution, en demande de fusion, en comité de revue, en termes de livraison acceptable, bref, ce que l'on appelle un processus… Mais maintenant, on sait pourquoi telle modification a eu lieue, avec les fameuses 5 questions en W que se pose tout enquêteur rigoureux :

  • What : quoi qu'a été modifié ;
  • Where : où que la modif a été faite ;
  • Who : qui l'a faite ;
  • When : quand l'a-t-il enregistré ;
  • Why : pourquoi.

Merci les gestions de versions, merci git le plus utilisé d'entre eux !

Enfant du Futur Immédiat, je te disais au début que La gestion de version a apporté la solution ; Eh ben oui : la commande git blame (git dénonce) te dira qu'elle est l'andouille qui a rajouté ce bug dans la ligne 792 qui sévit depuis 4 mois.
Comme ça, tu peux aller le voir, lui mettre un soufflon, retourner à ta place, le dénoncer à ta hiérarchie, et revenir à ton projet.
Comment ça, brutal ?

Ah oui, j'oubliais, dans la poésie légendaire de son créateur Linus Torvalds, git est à l'origine une insulte. Et je vous em🜟☭⁂‱

[La suite de cette chronique est une adaptation d'un billet antérieur de l'auteur]

Auteur : DaScritch
Illustration : GIT Branch and tag model for Master, HotFixes & Releases, CC MiguelPDL

Pièces jointes

  • 0087-CPU-Enfant-TiresPousses(21-06-18).mp3

2 commentaires

  • 1 De Mat - 30/09/2018, 12:50

    Excellent... Mais j'ai l'impression qu'il manque la fin à partir de 4:29 ?

  • 2 De Mat - 30/09/2018, 12:55

    Au temps pour moi c'est la page de l'extrait ;-) vous pouvez jeter mes commentaires. Merci pour ces émissions que je n'ai decouvertes que très récemment ;-)

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées. Votre e-mail ne sera pas affiché.

Menu

Catégories

  • Programmes
  • Interviewes
  • Chroniques
    • Enfant du futur immédiat
    • Ainsi naquit
    • Artefact du passé
    • Feedback
    • Histoire
    • How to
    • La mascotte
    • Le Gourou
    • Lexique
    • Plantage
    • Standard
    • Archéologie du Futur
    • Légende
    • Paillasse du design
  • Hors micro
  • Teaser

Séries

  • Arrière-guichet
  • Au service informatique de Sa Majesté
  • Bio is the new Black
  • Bulletin de santé d´Internet 2017
  • Crie si tu sais…
  • Cryptoparty
  • Elles codent
  • Futurs alternatifs
  • Histoires de la cryptographie
  • Killed By App
  • Langages machine
  • lost and found
  • Made in Japan 日本製
  • Parce que c’est Notre Projet Souverain
  • Quelque chose de totalement différent
  • Radio numérique
  • Read That Funky Manual !
  • Situation critique
  • Webmasters

Toutes les séries

Mots-clés

  • communication
  • communauté
  • design
  • politique
  • infrastructure
  • développement
  • matériel
  • organisation
  • sécurité
  • éducation
  • électronique
  • logiciel
  • standard
  • éthique
  • prototypage
  • humour
  • maker
  • marketing
  • situation de crise
  • vie privée

Tous les mots-clés

Menu extra

Suivez-nous !

  • 🎵 Podcast des émissions
  • 🎧 …pour Android
  • 🎧 …via Apple Podcast
  • 🎧 …via Google Podcast
  • 🎧 …en newsletter
  • Comment faire

Réseaux sociaux

  • Twitter @CPUprogramme
  • @cpu@Mastodon.tetaneutral.net
  • LinkedIn company/cpuprogramme
  • Facebook /programmecpu
  • Nous écrire par e-mail

Développeurs

  • Da Scritch
  • Enflammée
  • Fs0c131y
  • Gabriel
  • Infested Grunt
  • Vicla
  • Solarus
  • Philippe Martorell
  • Megami Yume
  • Chris O'Brien
  • Élise Rigot
  • René Speranza
  • Toute l'équipe

Producteurs

  • Radio <FMR>
  • Silicium
  • Ça Fait Écho
  • Régie publicitaire

Code source (github)

  • CPU-Audio web component
  • Thème Dotclear "CPU-15"
  • CPU podcaster
  • Youtube future playlist

Pages juridiques

  • Documentation du programme
  • Licence de l'émission et des sonores
  • Politique de confidentialité 🍪
  • Mentions légales

Interviewes et chroniques en licence CC-BY-NC ⬜ Émissions © DaScritch et l'équipe pour Radio <FMR> ⬜ Propulsé par Dotclear