IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre chevronné

    Homme Profil pro
    développeur
    Inscrit en
    octobre 2013
    Messages
    1 512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : développeur

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 512
    Points : 1 933
    Points
    1 933
    Par défaut Outil de qualité en pré commit bonne ou mauvaise idée?
    Bonjour à tous.

    Une petite question qui touche un peut à la ci mais surtout à git.
    Vaut-il mieux run les outils de qualité en pré commit (test, lint) ce qui permet d'épargner la ci, et de lancer tout de même la ci pour valider après.
    Ou alors de faire directement en ci puisque de toute façon ça doit passer par là..

    Je me pose la question car une personne ma dis que c'était une mauvaise pratique d'utiliser le pré commit.

    Merci

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 256
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 256
    Points : 23 259
    Points
    23 259
    Par défaut
    Bonjour,

    C'est difficile de te donner une réponse précise hors contexte car, comme c'est souvent le cas avec Git, cela va dépendre en grande partie du type d'application que tu développes et du langage que tu utilises. En particulier, le fait d'utiliser soit un langage compilé, soit un langage interprété, va beaucoup influer sur la « continuité » de l'intégration et de la distribution de ton travail. Par conséquent, je ne sais pas qui t'a dit que le « pre-commit » était une mauvaise chose, mais si ça l'est, ça ne l'est que dans un contexte donné (ou alors, c'est considérer les codeurs comme des singes dont la rentabilité est mesurée aux nombres de lignes effectivement intégrées par jour, auquel cas il faut fuir).

    L'idée générale est d'éviter absolument ceci : https://xkcd.com/1296/ . Au contraire, l'usage est de préparer une série de commits propres, logiquement indépendants des autres si possible (pour pouvoir éventuellement en exclure certains au besoin) et proprement documentés, pour qu'il soient facilement explorés et examinés par ses pairs, et même par soi-même quand il s'agit ensuite de se replonger dans du code très ancien ou d'identifier la révision qui a introduit un bug intermittent (avec git bisect, par exemple). Cela se fait généralement en préparant une branche jusqu'à ce qu'elle soit propre et en la proposant à l'intégration via une pull request.

    En ce sens, tout ce qui peut t'éviter d'avoir à reconstruire tes commits est bienvenu et disposer d'outils de contrôle préalable est une très bonne chose… à condition qu'ils restent consultatifs ! Les outils qui imposent une marche à suivre sont une plaie parce qu'ils ne sont jamais parfaits (ni à jour) et que quand ils se trompent, ils obligent le développeur à faire des contorsions assez sales pour les contourner. Malgré cela, quand on a la main sur ces outils, il ne faut surtout pas s'en priver.

    L'exemple-type est la modification d'un format de fichier, par exemple en passant, pour les fichiers texte, du format UNIX (fins de ligne en LF seul) au format Microsoft (CR LF) ou vice-versa. Ça a l'air d'une petite manip' complètement transparente qui se fait en une opération dans son éditeur mais en réalité, elle impacte par définition toutes les lignes d'un fichier. Quand ensuite on passe ça à Git, on voit un différentiel sur l'intégralité du contenu et on introduit un effet « d'horizon » dans l'historique : plus moyen d'utiliser facilement « git blame », par exemple, puisque toutes lignes sont marquées comme modifiées à cet instant précis.

    Il n'est pas obligatoire d'utiliser de tels outils (la plupart des développeurs s'en tiennent à VIM) mais les ignorer volontairement en comptant sur la phase de CI, c'est un peu comme dire « vas-y, écris tout en une fois, je te dirai à la fin si c'est ce que je veux ou pas ». C'est le meilleur moyen pour avoir à tout recommencer plusieurs fois de suite.

  3. #3
    Membre expérimenté Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 153
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 1 153
    Points : 1 708
    Points
    1 708
    Par défaut Les deux mon capitaine
    Bonsoir

    Au boulot, nous avons des projets communs (=plusieurs développeurs) où nous avons mis en place tous ces contrôles côté serveur afin, entre autre, de s'assurer que le contrôle se fasse bien et d'une façon uniforme. Il en est effet possible qu'un développeur moins regardant supprime certains contrôles ou n'en fasse pas.

    Ceci permet aussi de ne pas bloquer le développeur le temps que les tests soient exécutés.

    A titre perso, je n'aime pas recevoir des mails de retour "Commit refusé", c'est frustrant je trouve. Perso, je lance tous mes checks sur ma machine, en pre-commit mais en fait, le plus souvent, manuellement (j'ai créé un script qui me lance les checks les uns après les autres).

    Cela me permet aussi de voir en temps réel le code qui est passé à la moulinette et qui est "refusé/amendé" (je pense à rector p.ex.). Je vois réellement mes lignes de codes et je vois la correction proposée ==> j'apprends en même temps ("Ah oui, c'est vrai, je devrais plutôt faire comme ceci...").

    Je peux aussi être plus strict pour certains contrôles (p.ex. Psalm ou PHPStan).

    Je suppose, donc, que la réponse à ta question est variable, selon les projets et les développeurs.

    Je dirais donc : faire les deux mon capitaine.

    Bonsoir.
    Christophe (cavo789)
    Mes scripts Open Source : https://github.com/cavo789

  4. #4
    Membre chevronné

    Homme Profil pro
    développeur
    Inscrit en
    octobre 2013
    Messages
    1 512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : développeur

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 512
    Points : 1 933
    Points
    1 933
    Par défaut
    Bonjour à vous deux,

    Merci beaucoup pour vos réponses très bien expliqué
    J'y vois plus clair, peut-être qu'imposer le check au pré commit est un peut rude et peut mettre du temps, je vais partir sur une commande makefile que le dev peut lancer ou non et le check en ci obligatoire.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 40
    Dernier message: 16/10/2012, 11h13
  2. Réponses: 11
    Dernier message: 15/10/2012, 01h20
  3. Cours vidéo, bonne ou mauvaise idée ?
    Par I_believe_in_code dans le forum Etudes
    Réponses: 4
    Dernier message: 16/08/2012, 10h26
  4. Réponses: 7
    Dernier message: 09/12/2011, 07h47
  5. Réponses: 17
    Dernier message: 25/09/2010, 10h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo