Est-ce que commettre / vérifier quotidiennement le code est une bonne pratique?

63

Je lisais la note de Martin Fowler sur l’ intégration continue et il cite comme un impératif «Tout le monde s’engage pour le réseau principal tous les jours».

Je n'aime pas engager de code tant que la section sur laquelle je travaille n'est pas complète et qu'en pratique, j'engage mon code tous les trois jours: un jour pour analyser / reproduire la tâche et apporter des modifications préliminaires, un deuxième jour pour terminer les modifications. et un troisième jour pour écrire les tests et le nettoyer ^ pour le soumettre. Je ne serais pas à l'aise de soumettre le code plus tôt.

Maintenant, je tire les modifications du référentiel et les intègre localement généralement deux fois par jour, mais je ne m'engage pas souvent, à moins de pouvoir effectuer un travail moins important.

Question: s'engager au quotidien est-il une si bonne pratique que je devrais modifier mon flux de travail pour l'adapter, ou ce n'est pas souhaitable?

Edit: J'imagine que j'aurais dû préciser que je voulais dire "commit" dans le sens de CVS (alias "push") puisque c'est probablement ce que Fowler aurait voulu dire en 2006 quand il a écrit ceci.

^ L'ordre est plus arbitraire et dépend de la tâche. Mon but était d'illustrer la durée et les activités, et non la séquence exacte.

version-control

— Traîneau
source

20

Vous pouvez valider votre code s'il compile et exécute une logique utile. Il est préférable d’engager du code dans des cycles courts si vous travaillez dans un environnement d’équipe.

— EL Yusubov

4

Martin Fowler assume-t-il un VCS qui n'est pas distribué?

— user16764

4

Notez la date de cet article: le 1er mai 2006. Git et Mercurial n’ont même pas commencé avant avril 2005, et j’ai l’impression qu’ils ont vraiment commencé à gagner du terrain vers 2008. Je ne trouve aucun article sur le site de Fowler faisant référence à cet article. à l’un d’eux avant 2009. Par conséquent, cet article de 2006 suppose clairement un système de contrôle de source centralisé comme SVN. Les conseils ne s'appliquent pas aux équipes utilisant un DVCS.

— Kyralessa

2

@Kyralessa: L'article indique même que "Subversion est le [système de contrôle de version] moderne" ".

— che

4

D'abord le code et ensuite les tests?

43

Je ne suis pas d'accord avec cette règle et je souscris à ce qu'a dit Mason Wheeler . Je voudrais ajouter quelques idées.

J'essaie de m'engager à chaque changement significatif: cela peut être plusieurs fois par jour si je corrige plusieurs petits bugs, ou une fois par semaine si je travaille sur un logiciel plus volumineux qui ne peut pas être utilisé par le reste du monde. le code de manière significative jusqu'à ce qu'il atteigne un état cohérent.

En outre, j'interprète committing comme la publication d'une révision significative qui apporte de nouvelles fonctionnalités à la base de code. Je pense que l’on devrait essayer de nettoyer le code avant de s’engager afin que les autres développeurs puissent comprendre le sens et le but du changement quand ils consultent l’historique des révisions. Moins il y a de changements dans l'historique des autres développeurs, mieux c'est: quand je regarde l'historique des révisions, je veux voir les incréments qui ajoutent des fonctionnalités significatives; Je ne suis pas intéressé par toutes les petites idées que chaque développeur avait et voulait tester avant de parvenir à la solution.

De plus, je ne pense pas que ce soit une bonne idée d'utiliser le serveur SVN (ou tout système de contrôle de version) comme une installation de sauvegarde sur laquelle l'instantané actuel du code est validé (à condition qu'il soit compilé): vous pouvez utiliser une clé USB ou un lecteur USB externe ou un disque réseau pour refléter votre code actuel afin qu'il ne soit pas perdu si votre ordinateur tombe en panne. Le contrôle des révisions et la sauvegarde des données sont deux choses différentes. La publication d'une révision n'est pas la même chose que l' enregistrement d'un instantané de votre code.

Enfin, je pense qu’il ne devrait pas être problématique de s’engager de temps en temps (c’est-à-dire uniquement lorsque l’on est vraiment satisfait de l’état actuel du code) et qu’éviter les conflits de fusion n’est pas une bonne justification pour commettre (trop) souvent. De nombreux conflits de fusion se produisent lorsque différentes personnes travaillent sur les mêmes fichiers en même temps, ce qui est une mauvaise pratique (voir par exemple le présent article , point 7). Les conflits de fusion doivent être réduits en scindant un projet en modules avec des interfaces claires et le moins de dépendances possibles, et en coordonnant le travail des développeurs afin que le code sur lequel ils travaillent se chevauche le moins possible.

Juste mes 2 cents.

MODIFIER

Une autre raison contre les commissions prématurées qui m'est venue à l'esprit est qu'une version (très) boguée ne peut pas être testée. Si vous vous engagez dans le coffre et que votre équipe de test teste tous les jours, il est possible qu’elle n’ait pas de version testable pendant quelques heures (ou un jour). Même si vous n'essayez pas de corriger le bogue et de simplement annuler vos modifications, une reconstruction peut prendre quelques heures. Avec, par exemple, cinq testeurs travaillant dans votre équipe, vous avez perdu 5 x 2 = 10 heures de temps par équipe en raison de l'inactivité. C'est ce qui m'est arrivé une fois, alors j'essaie vraiment d'éviter les commits prématurés au nom de commit le plus tôt possible .

— Giorgio
source

23

Un "commit" n'est pas une "publication". "Commit" signifie "instantané"; 'publier' s'appelle 'push' dans scm-lingo. Bien entendu, SVN ne fait que fusionner les deux concepts en un seul, ce qui rend impossible de nombreux workflows sensibles, mais il s’agit d’une limitation de l’outil, et non des workflows de contrôle de source en général.

— tdammers

3

Revision control and data backup are two different thingsOui, je me sens vraiment comme ça.

— Traîneau

1

@tdammers: je voulais dire publier de manière informelle: tant que le code est sur mon ordinateur, mes modifications privées du code commun. Dès que je l'engage, il est publié, connu du reste de l'équipe et intégré à l'historique du projet.

— Giorgio

1

Dans ce cas, «commit» est probablement le mauvais mot. De nombreux SCM autorisent les commits locaux et le partage de votre code avec le reste de l'équipe est une action distincte, généralement appelée "push". Encore une fois, SVN combine les deux concepts, mais il s’agit d’une limitation de l’outil. Si cela gêne votre flux de travail, envisagez de passer à un autre SCM.

— tdammers

@tdammers: établir une distinction claire entre la validation locale et la publication serait un pas en avant. En SVN, je peux utiliser une branche distincte pour cela. Mais encore une fois, je me demande pourquoi je voudrais garder une trace d’une révision qui n’a pas beaucoup de sens pour moi. Je ne suis pas convaincu que je veuille une nouvelle révision (même une version privée) simplement parce qu'il est 5 heures et que je rentre chez moi. Je préfère avoir une sauvegarde à la place.

— Giorgio

107

Je commets du code plusieurs fois par jour . Chaque fois que je parviens à un point où le code est suffisamment complet pour être compilé et ne casse pas autre chose, il entre.

Vous devriez envisager de rompre votre travail pour pouvoir vous enregistrer en toute sécurité quelques fois par jour.

Les raisons pour cela sont deux:

Tout travail non enregistré peut être perdu - votre ordinateur peut avoir une défaillance catastrophique. Dans ce cas, plus vous attendez, plus vous perdez de travail.
Plus vous faites de travail sans vous enregistrer, plus vous aurez de code à intégrer lorsque vous déciderez enfin de le créer. Cela introduit plus de chances de conflits et de problèmes de fusion.

— Oded
source

2

Si vous avez un grave problème de conflits et de problèmes de fusion, cela signifie que votre chef de projet ne fait pas son travail. Plusieurs cas impliquant des fonctionnalités similaires doivent aller au même développeur, précisément pour éviter que deux ou plusieurs codeurs ne piétinent le travail de chacun.

— Mason Wheeler

14

@MasonWheeler - Après 3 jours de travail qui n'a pas été engagé, il y a de fortes chances pour que l'un ait touché à du code que d'autres ont en même temps. Si de nombreux programmeurs le font, même le meilleur chef de projet ne peut éviter les conflits.

— Oded

3

@ Old: Peut-être. Je suppose que ma réponse est influencée par mon expérience sur une base de code suffisamment importante pour que nos développeurs (environ une douzaine de codeurs de l'équipe) aient tous tendance à assumer des responsabilités qui ne se chevauchent pas. Je ne sais pas à quel point ce serait différent sur des projets plus petits.

— Mason Wheeler

3

@ArtB - Que se passe-t-il s'il y a quelqu'un comme vous qui ne s'enregistre que tous les 3 jours? Ou une fois par semaine? Vous comptez sur les autres pour prendre les bonnes décisions.

— Oded

3

Quand j'ai lu la question, ma réponse a été "est-ce comme demander si c'est une bonne idée de prendre une douche chaque semaine"?

— Andrew Grimm

39

Adhérer à une méthodologie ou à une pratique sans comprendre les raisons qui la sous-tendent n'est jamais une bonne idée. C'est de là que provient la programmation culte du cargo.

Par conséquent, "je devrais m'engager tous les jours parce que Martin Fowler l'a dit" est tout simplement stupide. Et parfois, ce n'est pas pratique aussi. Si vous travaillez sur une nouvelle fonctionnalité compliquée, vous ne pourrez peut-être pas en arriver à une vérification tant que vous n'y avez pas déjà travaillé pendant quelques jours.

Cela ne signifie pas que vous devez vous assurer que tout est parfait avant de l'enregistrer. C'est un bon moyen de perdre du travail en cas de problème. La bonne chose à faire est de développer et d’utiliser un bon jugement en la matière. Les règles de base ne peuvent que vous aider beaucoup.

— Maçon Wheeler
source

1

Ensuite, s’il s’agit d’une intégration / développement d’entités complexe, c’est toujours une grosse perte que de ne pas la valider, peut-être pas dans le coffre, mais au moins dans une branche pour cette fonctionnalité, c’est le rôle de ces branches!

— Vincent B.

2

Que voulez-vous dire par «mérite d'être visité»? Si cela ne casse pas le code de quelqu'un d'autre, pourquoi ne l'enregistreriez-vous pas?

— Kirk Broadhurst

2

"Qu'est-ce que vous voulez dire par" ça vaut la peine de vérifier "? Si cela ne casse pas le code de quelqu'un d'autre, pourquoi ne pas l'enregistrer?": Parce que je ne veux pas conserver les anciennes copies du code simplement parce qu'elles existaient déjà point dans le temps. Je veux aussi conserver une ancienne copie du code s'il contient des informations utiles que je souhaiterais peut-être récupérer ultérieurement. Sinon, je ne fais que produire du bruit inutile dans l'historique des révisions.

— Giorgio

3

+1 J'ai déjà travaillé dans une équipe où nous devions vérifier le code dans le vcs tous les jours, même si le code était une pointe ou une enquête inutile. Cela s’est avéré inefficace et peu rentable, en particulier parce qu’il fallait un entretien périodique pour nettoyer les vcs. Cela était dû à une combinaison de paranoïa et risquait de perdre un peu de temps pour refaire quelque chose, et parce que le responsable avait lu dans un livre que vous devriez vous engager tous les jours. Un exemple extrême peut-être, mais sérieusement, si vous n'avez pas le jugement de savoir s'il est «intéressant» de vérifier quelque chose, vous n'êtes probablement pas bien adapté à ce travail.

— S.Robins

14

Oded a donné deux raisons importantes pour engager le code aussi souvent que possible. J'ajouterai quelques autres:

Pendant que vous travaillez sur votre morceau de code, d’autres peuvent avoir besoin de fonctions sur ce code. Ils ne devraient pas attendre 6 jours pour l'obtenir. Dans ce cas, mes collègues créent généralement un prototype dans mon morceau de code, le commettent, j'ajoute le corps et le commets à nouveau. Et cela se fait généralement en quelques heures.
Le code «commun» vise à ce que tout le monde voie chaque changement le plus rapidement possible. Si le morceau de code sur lequel vous travaillez est totalement séparé du travail des autres et que vous ne les faites pas attendre, il est recommandé de créer une branche sur laquelle travailler, puis, si tout réussit, de le fusionner. la ligne principale.

— SuperM
source

1

Pourquoi cette réponse avec (OMI) est-elle la seule réponse correcte et exacte (point 2) aussi peu notée?! Bien sûr, c'est le point d'une branche! @Mason Wheeler: Vous aimez donc coder plusieurs jours sans commettre une seule fois? Alors pourquoi utiliser un système de contrôle de version?!

— Vincent B.

2

C'est la bonne réponse. Si votre tâche exige plusieurs jours de travail avant de pouvoir être utilisée, branchez-la. Sinon, vous vous engagez à chaque fois que cela fonctionne pour vous assurer que les membres de l'équipe disposent de la dernière version, qu'ils peuvent tester son fonctionnement et qu'ils identifient les fonctionnalités ajoutées / manquantes dès que possible.

— Kirk Broadhurst

"Vous aimez donc coder plusieurs jours de manière brute sans commettre une seule fois? Alors pourquoi utiliser un système de contrôle de version?!": Parce que vous souhaitez éventuellement valider une révision, même si vous n'êtes pas obligé de commettre aveuglément chaque jour. Il vous appartient plutôt de décider si vous vous engagez plusieurs fois par jour ou si vous travaillez trois jours de suite sans vous engager. Je ne vois vraiment pas l'intérêt de valider une fonctionnalité inachevée que personne ne peut utiliser: faites simplement une sauvegarde, le lendemain, vous pourrez la terminer et la valider.

— Giorgio

8

Je crois fermement en l'engagement de tous les changements logiques qui méritent d'être conservés. Engagez-vous souvent, et si le code ne vaut pas la peine d'être gardé, revenez-le à l'état pur. Plus vous attendez pour remettre / publier votre code, plus il est difficile à implémenter et plus vous rencontrerez de problèmes. Vous obtiendrez également des commentaires sur vos contributions beaucoup plus rapidement:

Est-ce qu'ils cassent la construction?
reproduisez-vous les efforts d'un autre membre de l'équipe?
faites-vous quelque chose de mal?
ou les gens attendent-ils de vous?

Les petits changements sont beaucoup plus faciles à gérer.

En outre, il convient de noter la différence entre différents systèmes de contrôle de version. Certains, tels que Git (distribué), vous permettront de valider et de contrôler l’ensemble de votre historique localement, en appuyant uniquement lorsque vous êtes prêt à publier. D'autres, comme SVN (centralisé), combinent les deux étapes, ce qui rend les petits commits très inefficaces.

N'oubliez pas que vos commits sont essentiellement des documents de modification. Lorsque les choses vont mal, vous serez heureux d'avoir plus d'histoire que pas assez. Un seul engagement pour une semaine de travail me semble inutile. Je finirais par lire chaque ligne de code modifiée plutôt que le résumé de chaque bloc logique.

— Adrian Schneider
source

5

Je pense que la plupart des réponses ici manquent l’un des points principaux de la déclaration de Martin Fowlers. Ceci est lié à l' intégration continue . Le code qui n'est pas archivé (poussé / publié / fusionné) dans la ligne principale n'est pas testé.

Cela ne doit pas être lu comme un encouragement à valider le code que vous avez sur votre machine locale chaque fois qu'il est temps de quitter le bureau. Comme l'ont souligné plusieurs autres personnes ici, ce serait mauvais, cela casserait la construction et causerait une ligne principale instable.

Cependant, il est encourageant d'essayer d'apporter vos modifications par petites étapes qui peuvent être archivées dans la ligne principale sans causer de problèmes. Ceci encourage l'évolution du code au lieu de tout déchirer et de réécrire.

Maintenant, qu'est-ce qui est bien avec cette façon de travailler?

Ne pas engager de gros morceaux de code ou des modifications révolutionnaires réduit les risques de rupture de la construction.
Si votre commit rompt la construction, il est assez simple d'identifier les problèmes, de l'inverser puis de valider rapidement une version corrigée.
En vous assurant que tous les tests sont exécutés à chaque modification mineure du code, vous évitez d'introduire des bogues subtils ou des régressions pouvant découler de la croissance du code en dehors du schéma d'intégration continue.

Bien sûr, tous les changements ne se prêtent pas à cette approche. Comme d'autres l'ont souligné, aucune règle n'est absolue. Toutefois, pour les modifications qui devraient rester longtemps en dehors de la ligne principale, configurez une ligne principale alternative avec son propre système d'intégration continue et suivez la même approche. Avec les VCS distribués d'aujourd'hui, c'est une chose assez facile à faire.

— harald
source

+1: "Bien sûr, tous les changements ne se prêtent pas à cette approche." Je pense que c'est le point. Je trouve les conseils de Fowler acceptables, mais il faut juger au cas par cas. Au lieu de cela, ce conseil est souvent généralisé à une règle absolue et suivi sans autre considération.

— Giorgio

@ Georges, je suis tout à fait d'accord avec vous sur ce point. Aucun conseil ne doit être considéré comme une règle absolue, peu importe qui est derrière.

— harald

Quelques idées supplémentaires à ce sujet. "Le code qui n'est pas archivé (poussé / publié / fusionné) dans la ligne principale n'est pas testé.": Je conviens que c'est un bon principe et qu'il ne faut pas attendre des semaines avant de procéder à l'enregistrement et au test du code. Cependant, l' application aveugle de ce principe peut conduire à une application cassée qui ne peut même tester (je l' ai vu en direct: l'équipe de test tout reste inactif pendant plusieurs jours et ne peut pas tester quoi que ce soit jusqu'à ce que le code est ramené dans un état utilisable). Peut-être que ce que d'autres utilisateurs ont écrit est applicable à certaines situations, mais ce n'est pas en général.

— Giorgio

1

Vérifier le code instable n’est jamais acceptable. Un commit qui rompt l'EC doit être annulé. Si vous effectuez souvent de petits changements incrémentiels, il y a moins de chance d'introduire une telle rupture que si vous avez un gros changement qui n'a pas été testé depuis longtemps. Il peut également être plus facile de revenir en arrière s’il casse la construction. Mais comme vous le dites, il n’ya parfois aucun moyen d’échapper à un changement perturbateur. Ensuite, peaufinez-le du mieux que vous pouvez et testez-le soigneusement avant de le commettre. Le but n'est pas de suivre des règles, mais de comprendre d'où vient le conseil.

— harald

3

Arguments pour vérifier chaque jour:

Le code est stocké et sauvegardé en cas de défaillance du disque dur
L'activité peut être enregistrée dans les notes de commit ( qu'est-ce que j'ai fait jeudi ...? )
L'intégration avec la base de code existante se produit plus tôt et en plus petits morceaux, en identifiant les conflits ou en fusionnant les problèmes plus rapidement
Votre équipe a une visibilité de ce sur quoi vous avez travaillé
Vos collègues peuvent travailler contre vos interfaces plus rapidement, ce qui leur laisse plus de temps pour s'intégrer à votre «gros morceau de code complexe».
Votre code sera testé dans le monde réel plus tôt, ou du moins exposé à une utilisation plus importante que celle que vous lui en donnerez, ce qui permettra d'identifier plus tôt des bogues ou des omissions.

Arguments contre l’enregistrement quotidien:

Pas besoin ou pas envie
Je n'ai pas encore nettoyé mon code, c'est un gâchis
Pas le temps

Je ne crois pas qu'il y ait de bonne raison de s'enregistrer moins de jour en jour en dehors de la paresse ou de la désorganisation. Rien de pire que de voir que le code exécuté dans l'environnement de développement ne correspond pas à celui de la branche de développement, car quelqu'un "n'a pas encore fini" et ne s'est donc pas enregistré.

J'adorerais me tromper, merci de me faire savoir tout argument légitime contre l'enregistrement quotidien.

— Kirk Broadhurst
source

"Je ne crois pas qu'il y ait de bonne raison de s'enregistrer moins de jour en jour en dehors de la paresse ou de la désorganisation.": Je crois le contraire pour exactement la même raison. Je peux prendre le temps d'examiner l'état actuel du code et de décider s'il contient des informations pertinentes qu'il convient de retenir, ou, si je suis paresseux et désorganisé, je peux simplement l'enregistrer (et produire des révisions supplémentaires avec peu d'informations contenu) aussi longtemps qu'il compile.

— Giorgio

1

Je comprends votre point de vue, il ne faut pas être fainéant et nettoyer son code tous les jours afin de pouvoir l’enregistrer. Par contre, lorsqu’on travaille sur un code complexe, c’est difficile à réaliser car le nettoyage peut prendre plusieurs heures. et vous ne pouvez pas passer plusieurs heures chaque jour uniquement pour nettoyer votre code.

— Giorgio

@ Giorgio Vous avez donc passé plusieurs jours à nettoyer votre code? J'ai donné quelques bonnes raisons pour vérifier quotidiennement - votre raison est que vous devrez nettoyer votre code? Il suffit d'écrire le code plus propre.

— Kirk Broadhurst

Ce n'est pas toujours possible, par exemple si je développe à partir de zéro un code complexe (> 4000 LOC) qui nécessite beaucoup d'expérimentation pour réussir. En fin de compte, il est fort possible que le code soit un peu brouillon et que je ne souhaite pas le réparer avant que mon état ne soit cohérent, c'est-à-dire quelques jours plus tard. Malheureusement, je ne suis pas si intelligent que j'ai fini, le code parfait se forme dans mon esprit et je peux toujours tout écrire en quelques heures (c'est-à-dire au bout d'une journée). J'ai eu une telle expérience récemment et le cycle de développement typique (d'un état cohérent à l'autre) était de 2, 3 jours.

— Giorgio

@Giorgio n'avez-vous pas de branche de développement dans laquelle vous vous connectez? Le code doit être archivé afin que d'autres personnes puissent l'examiner et le tester également.

— Kirk Broadhurst

2

Si vous voulez dire «commettre» par «fusionner dans le réseau principal», vous ne devriez certainement pas le faire tous les jours dans un projet de logiciel diffusé aux clients. Vous devez fusionner les modifications effectuées et testées pour que la ligne principale soit toujours opérationnelle et libérable, et non dans un état de rupture avec des fonctionnalités à moitié terminées.

Cependant, le luxe de pouvoir utiliser le contrôle de version distribuée actuel est que vous pouvez à la fois garder la ligne principale stable et faire votre travail à git/hg/whatever commitchaque fois que vous souhaitez préserver l'état de choses. Je le fais une fois toutes les quelques heures et certainement à la fin de chaque journée.

Avec DVCS, vous pouvez publier votre travail, collaborer avec d’autres membres de votre équipe et le tenir au courant des modifications apportées à la branche principale. Vous pouvez faire tout cela sans nuire à la stabilité du code dont dépendent vos clients et / ou d’autres équipes.

À une époque où Subversion était la technologie la plus récente et où il était impossible de créer des fourchettes de fonctions sans trop de difficultés, il aurait peut-être été préférable d'avoir une ligne principale dans laquelle plusieurs fonctions étaient en construction simultanée. Mais cette supériorité ne dépasse pas 2010.

— che
source

2

Dans Team Foundation Server, vous pouvez «Shelve», ce qui n’est pas la même chose qu’un enregistrement, mais vous permet simplement de sauvegarder votre code afin que, si votre machine meurt, vous n’ayez pas perdu les modifications.

J'ai également vu des éditeurs de logiciels qui ont une "ligne de développement" et une "ligne principale". Les développeurs sont libres de se connecter à la ligne de développement dès qu'ils le jugent utile et seul le chef d'équipe a accès à la ligne principale. Ils sont donc responsables de la copie du code de dev à main quand il est prêt pour la production.

— Matt Wilko
source