Quelles sont les bonnes pratiques avant d'archiver le code source?

Question

Mon équipe utilise Team Foundation Server pour le contrôle des sources, et aujourd'hui j'ai corrigé quelques bugs et une application de test de fumée avant de m'enregistrer mais j'ai oublié de commenter du code. (Ce code a rendu l'interface utilisateur un peu étrange.)

Je veux savoir quelles sont les bonnes pratiques avant d'archiver le code - je ne veux pas refaire ce genre d'erreur.

crudcore · Accepted Answer

Une chose que j'ai l'habitude de faire, c'est toujours de regarder les différences de chaque fichier que je suis sur le point d'archiver, juste avant de les archiver.

Oded · Answer

Vous ne devez jamais archiver de code commenté. Si vous avez du code qui doit être commenté avant les enregistrements, vous le faites mal.

Quant aux règles:

Obtenez le dernier
Correction des conflits de fusion
Construire

3.1 Correction des erreurs de construction
Exécuter des tests

4.1 Correction des tests cassés
Passez à 1 (jusqu'à ce qu'il n'y ait rien de nouveau à obtenir)

Enregistrez-vous uniquement lorsque toutes les étapes sont terminées.

Voir danse d'enregistrement .

Autres bonnes pratiques:

Consultez la liste des fichiers à archiver pour vous assurer qu'il s'agit bien des fichiers attendus.
Passez en revue les modifications pour chaque fichier (suppressions/ajouts/différences)

AviD · Answer

Je n'essaie pas d'être trop un pantin ici, mais l'hypothèse de cette question (et toutes les réponses sauf une) s'applique principalement aux VCS centralisés, tels que TFS, SVN, Perforce, etc.
Très bien, c'est ce que l'OP utilise.

D'un autre côté, cependant, lorsque vous utilisez DVCS (comme Mercurial et Git), vous ne devriez généralement pas attendre pour vous enregistrer, et la plupart des choses mentionnées dans les réponses - telles que les différences, obtenir la dernière version, fusionner, etc. - ne sont pas nécessaires . Même des choses comme les revues de code et les tests sont mieux à faire après l'enregistrement (mais peut-être avant de pousser, selon ...)
La seule exception que j'ai vue ici (jusqu'à présent) est l'association avec un élément de travail. Bien sûr, commenter l'enregistrement est également bon ...

idbrii · Answer

Trois choses que je n'ai pas vues dans les autres réponses:

Inclure de nouveaux fichiers

Recherchez de nouveaux fichiers qui ne font pas partie de votre liste de modifications
Peut être spécifique aux SCM comme Perforce - vous devez lui dire tout ce qui est dans votre changement.

Rétablir les fichiers inchangés

Je déteste quand je regarde les changements des autres et il y a une liste de modifications avec neuf fichiers mais seulement trois d'entre eux ont été modifiés.
Je rétablis également les fichiers avec des espaces ou des changements autrement dénués de sens.

Vérifiez votre commit soumis

Assurez-vous que la version reste verte après votre validation.
J'avais l'habitude d'avoir une deuxième machine que je synchroniserais, construirais et exécuterais après mes validations, donc si quelque chose tournait mal, je pouvais facilement intervenir et le réparer.

Deux choses quand j'utilise Git:

Commissions atomiques:

N'étape que les modifications fonctionnelles individuelles pour la validation.
Faites des commits aussi petits que possible. Rendez-les faciles à corriger, à rétablir et à comprendre.
J'utilise git add --patch pour diviser ma modification en plusieurs parties si nécessaire.

Afficher les différences lors de la synthèse

Je vérifie toujours avec git commit --verbose afin que je puisse voir un diff de ma modification pendant que je tape mon message de validation. (Ou j'utilise mon patch git-vim pour montrer la différence.)
Cela vous permet de passer en revue vos modifications et de décrire l'intégralité du commit. Parfois, j'attrape des changements involontaires à ce stade. (Décrire votre changement vous aide à y penser.)

Throwback1986 · Answer

Rechercher et remplacer les mots maudits ;-)

guildsbounty · Answer

Quelques éléments de "bonnes pratiques" que j'applique aux serveurs de mon équipe sont assez simples. Tout d'abord, avant de vous enregistrer, vous devez toujours obtenir la dernière version et exécuter une génération locale, pour vous assurer que personne d'autre n'a vérifié quoi que ce soit avec lequel votre code sera en conflit. De plus, prenez soin de tout conflit de code sur votre machine locale, pas sur le serveur. Une fois que votre code, avec le dernier code téléchargé, a été confirmé pour générer et fonctionner correctement, vous êtes prêt pour la prochaine étape. Exécutez tous les tests automatisés, puis commencez votre enregistrement pour vous assurer qu'ils fonctionnent toujours correctement. Ensuite, juste pour être sûr, obtenez à nouveau le dernier.

Il est possible, en tant qu'administrateur TFS, d'imposer des commentaires sur tous les enregistrements. Je recommanderais toujours de mettre des commentaires d'enregistrement pour votre travail, qu'il soit appliqué ou non. Si vous avez la possibilité de le faire, appliquez-le. Assurez-vous que les commentaires sont, au minimum, un résumé général de ce que vous avez changé depuis la dernière fois que vous avez archivé votre code. De cette façon, si quelque chose ne va pas, vous pouvez parcourir les check-ins et voir, en gros, ce qui était changé dans ce check-in. Cela facilite le débogage d'une version cassée.

De plus, si vous avez des privilèges d'administrateur TFS, appliquez des builds roulants sur les enregistrements (pour vous assurer que tout le monde sait immédiatement si leur enregistrement casse quelque chose), et vous pouvez configurer le serveur pour effectuer un enregistrement sécurisé ( si le code archivé rompt la construction, le serveur la rejette), ou vous pouvez simplement lui faire créer un bogue et l'attribuer à celui qui a cassé la construction.

Il y a quelques autres options que vous pouvez activer ou désactiver pour garder tout bien en ordre, ou suggérer à votre administrateur TFS d'activer pour garder les choses agréables et propres ... mais elles sont largement préférées

Fanatic23 · Answer

Si vous vous connectez à partir de Windows, vérifiez si votre code n'a pas ces caractères ^ M invisibles - les éditeurs sous UNIX donnent souvent des erreurs/avertissements à cause de cela.

Essayez également de remplacer les tabulations - différents utilisateurs finiront par voir les tabulations différemment certains avec 4 espaces, certains 8 et pas bon pour la lisibilité du code.

La meilleure approche à mon humble avis est d'avoir un script prédéfini vérifier votre code par rapport aux directives de codage de votre organisation. De nombreux systèmes de contrôle des sources ont cette fonctionnalité.

tenpn · Answer

Dans mon entreprise, nous utilisons des avis d'enregistrement. Celles-ci n'ont pas besoin d'être détaillées, mais le simple fait de montrer à quelqu'un les différences dans votre liste de modifications et de les parcourir mettra parfois en évidence la faute de frappe que vous avez manquée lors des tests.

Notre serveur de contrôle des sources ne vous permettra pas de vous enregistrer à moins que vous ne notiez le nom du réviseur dans les commentaires (sous la forme! Initiales, par exemple! BW si Bruce Wayne a fait votre évaluation). L'évaluateur reçoit un e-mail indiquant qu'il a aidé à évaluer. Ceci est ouvert à une exploitation évidente mais semble fonctionner assez bien.

mpeterson · Answer

Dans la mesure du possible, j'aime associer un enregistrement à un élément de travail. Cela vous donne quelques informations contextuelles sur POURQUOI cela a été changé, pas seulement sur CE QUI a été changé. TFS a un système de suivi des éléments de travail assez décent, donc c'est assez trivial à faire au moment de l'enregistrement.

(ceci en plus de revoir les différences de mes changements)

John Saunders · Answer

Une petite chose que je fais est de ne pas archiver les fichiers qui n'ont pas vraiment changé. Ces fichiers peuvent avoir été modifiés par inadvertance ou avoir été impliqués dans des refactorisations qui ont été soit annulées, soit rendues sans objet.

De cette façon, votre ensemble de modifications (associé à un élément de travail) contient exactement les fichiers nécessaires pour satisfaire l'élément de travail.

edelwater · Answer

Pour combiner toutes les réponses ici et donner une liste de contrôle complète

[check in/check out] vous ne devez pas vous connecter directement au flux sur lequel d'autres travaillent. Vous devez avoir une stratégie de flux: par ex. par développeur un flux dans lequel vous pouvez vous enregistrer et extraire indépendamment sans déranger les autres: votre travail sera en sécurité mais dans votre propre flux de développement donc [uniquement dans votre propre flux de développement]. À chaque archivage, vous l'associez à un enregistrement de changement afin que vos changements soient atomiques par rapport à ce changement appelé le jeu de changements (afin que vous puissiez distribuer des rfc/bugs individuels etc ... sans avoir à fournir `` tout '').
[puis rebaser avec votre flux d'équipe] cela signifie que vous obtenez les modifications des autres dans votre propre flux. Pendant cette opération, vous pouvez voir dans la boîte de dialogue de fusion tous les "diffs" et les parcourir ou ... s'il y en a des milliers et/ou si vous utilisez non pas du code mais aussi par ex. modèles de données/projets siebel etc ... s'appuient soit sur des fusions non triviales, des fusions triviales automatiques et triviales, la dernière catégorie contient les plus difficiles. N'oubliez pas que vous travaillez toujours dans votre propre flux.
[rebase complet] Si tout va bien, enregistrez toutes les modifications que vous venez de recevoir du flux d'équipe: votre propre flux est maintenant à jour
[livrer] livrez maintenant votre travail au flux d'équipe. SI vous ne souhaitez pas tout livrer, vous pouvez également sélectionner par exemple 1 RFC spécifique avec ces versions spécifiques de fichiers ou un ensemble de RFC/défauts résolus.
[test livrer] ça devrait aller bien mais comme il y a des chances que quelqu'un entre-temps change aussi: vous pouvez tester si votre travail fonctionne avec les dernières modifications sur le flux d'équipe. Avec les mêmes boîtes de dialogue de fusion montrant les différences.
[livraison complète] terminez votre livraison et votre travail est maintenant dans le flux d'équipe.

Pour le rendre plus complexe: comme il y a toujours la possibilité que le travail que vous avez livré = ok MAIS vous travaillez déjà sur une autre version, vous devez toujours établir une base de référence après la livraison et indiquer à partir de quelle base celle-ci est préférée pour les autres utilisateurs. . Cela garantit que les autres développeurs obtiennent une version recommandée et non la dernière version sur le flux (si vous travaillez dans ce scénario). Il s'agit également d'une triple vérification de sorte que même si les dernières versions du flux d'équipe sont "mauvaises", ce ne sont toujours pas celles que les autres rebasent ou consultent et votre gestionnaire de configuration peut alors fusionner la version précédente vers la version suivante pour annuler. votre livraison.

la réponse de l'histumness se produit 2 fois: aux étapes 2 et 6
la réponse d'Oded lors de l'enregistrement: idem mais une couche supplémentaire de livraison et de rebasage lors de l'enregistrement/du départ pour vous assurer que vous travaillez isolé et que les erreurs peuvent toujours être facilement supprimées même dans les étapes ultérieures
la réponse de guildsbounty a répondu: la dernière étape est l'étape 2. Pour la construction: cela dépend vraiment si vous AVEZ une construction ... dans mon monde, vous avez des entrées de modèles de données, de documents Word, de feuilles d'exigences, de données de configuration d'Informatica, siebel, etc .., et oui aussi Java code, code .net etc ... que tout devrait se mélanger. Donc il n'y a pas vraiment de "build" ici mais plus d'intégration plus haut selon si par exemple, cette construction unique à partir de votre "code" s'intègre à tout le reste, car vous ne pouvez pas savoir avec certitude s'il s'agit de choses d'intégration et, en fonction de leurs environnements de test, il pourrait être compilé. a besoin de quelque chose d'une autre équipe.
la réponse de guildsbounty sur les commentaires et requis: je pense que chaque environnement dans lequel vous n'avez pas d'intégration de VERSIONS et de changements dans les ensembles de changements (et type: défauts, RFC, hotfi) n'est pas mature. Je pense que son chaos si vous ne pouvez pas par exemple automatiser les notes de publication avec le nombre de bogues et de rfcs soumis qui sont cliquables jusqu'aux versions exactes qui sont touchées (car par exemple la version 1 et la version 3 de hello.c pourraient très bien être livrées mais la version 2 n'aurait pas dû être livrée parce que ce truc il y aurait une partie d'une version ultérieure, mais certains noob l'ont déjà inséré) (cela signifie donc une décision manuelle SI vous souhaitez également retirer la version 3 de hello.c MAIS retirer la version 3 signifie que vous devez également retirer tout autre version touchée par ce RFC/défaut, vous devez donc pouvoir facilement et rapidement avec un outil pour supprimer tout)) (même si plusieurs développeurs ont travaillé sur des parties de ce même RFC), mais au moins vous avez besoin de choses autour pour décider dessus etc ...). Une documentation supplémentaire est toujours pratique mais en associant des ensembles de modifications, vous obtenez le cercle complet: une version <- un ensemble de modifications <- des éléments de travail <- un ticket/rfc/défaut <- une exigence. Signification: vous savez quelles exigences sont entièrement ou complètement livrées: une exigence a plusieurs RFC ou bogues ou autre. Le RFC a plusieurs éléments de travail pour plusieurs personnes. cet élément de travail correspond à un ensemble de modifications qui existe d'un ensemble de versions (par exemple, les versions 1 et 3 de hello.c sur le flux d'intégration qui ne sont bien sûr PAS les versions 1, 2, 3, 4, 5 dans votre flux de développement cette version 3 dans le flux d'intégration correspond à) (d'où une arborescence de versions et des outils pour y travailler)
le commentaire de luis.espinal: ne pas interrompre la construction est revérifié dans le rebase et livrer toujours ... il y a des livraisons plus élevées pour les `` gestionnaires de versions et les build meisters '' qui devraient voir les ensembles de modifications et les lignes de base comme leurs informations. "Ne travaillez jamais directement sur la branche principale" oui, la structure du flux peut être grande ou simple mais essentiellement: les développeurs ont leur propre flux, ils livrent à un flux d'équipe qui livrent à un flux de version. -> afin que les livraisons de toutes les équipes (par exemple, l'équipe de documentation, l'équipe des exigences, les équipes de développement, l'équipe de test) soient dans leurs flux d'équipe et qu'un responsable de version ou un gestionnaire de configuration saisisse les lignes de base qui devraient aller dans une version et s'assure ainsi que documentation correcte avec les versions de test correctes/documents avec l'exigence correcte avec les versions de code correctes sont tous en ligne pour une version.

Dans votre exemple, vous indiquez que vous avez oublié de mettre en commentaire le code. Des erreurs se produisent. Le système de gestion de configuration qui l'entoure devrait s'en occuper. Cela peut vraiment être par exemple des milliers de changements interviennent et les "builds" et "intégrations" ont lieu dans une hiérarchie de flux sur différents serveurs chaînés et traités dans le temps. Ainsi, même si après 5 mois, votre code commenté est testé sur un serveur d'intégration, car votre code doit être intégré à d'autres codes et systèmes, il devrait toujours être possible de supprimer atomiquement votre ensemble de modifications et de continuer. La meilleure pratique se situe donc plus ou moins à un niveau supérieur. La conception globale des flux de gestion de la configuration devrait s'en occuper. Pour les développeurs individuels, la meilleure pratique est bien sûr de valider/test unitaire. Mais de la vue d'ensemble pour "le faire fonctionner", la meilleure pratique est de suivre le système et de toujours fournir cette méta-information des ensembles de modifications connexes pour les gars plus tard dans la chaîne.

luis.espinal · Answer

Certains des éléments suivants s'appliquent plus que d'autres (ou sous différentes formes) en fonction de votre SCM, alors voici:

Ne cassez pas la construction - vérifiez uniquement le code qui compile.
Commentez vos entrées (et éventuellement vos sorties si votre SCM vous donne cette option.)
Ne laissez pas les choses incontrôlées pendant de longues périodes.
Enregistrez-vous souvent (plusieurs fois par jour si possible.)
Étiquetez de manière significative.
Étiquetez régulièrement.
Ne travaillez jamais directement sur la branche principale.
Chaque version en production doit avoir sa propre étiquette (et si possible une branche en lecture seule de la branche principale). Dans la mesure du possible, faites de même pour les versions de test UAT/Intégration/Pré-production.
Vous devriez être en mesure de construire exactement ce qu'il est en production à partir de ce qui se trouve dans votre SCM et à partir d'une étiquette.

[~ # ~] note [~ # ~] : certains des éléments ci-dessus semblent plutôt évidents, mais vous ne croiriez pas combien de personnes travaillent réellement sur la branche principale ou modifiez d'abord la production puis créez manuellement des deltas pour passer au contrôle de version ... directement sur la branche principale ... et avec Étiquettes. Douce comme de la bile fermentée mélangée à du jus d'aisselle non lavé ... ouais, comme ça.

ctrl-alt-delor · Answer

Ayez une liste de contrôle personnelle. Commencez-le vide lorsque vous vous trompez, à une entrée. Lorsqu'il devient une seconde nature, supprimez-le de la liste.

Exécutez les tests. S'ils réussissent, vérifiez-le. Si vous vous trompez et que quelque chose dépasse les tests, écrivez un test.

gablin · Answer

Toujours, toujours, toujours, vérifiez que les modifications que vous avez apportées ne cassent pas la construction. Des changements particulièrement mineurs qui peuvent sembler insignifiants.

Une fois que j'ai fait un changement très mineur, je ne pensais pas que cela causerait des problèmes juste avant de quitter le travail pour le week-end. Effectivement, ce petit changement a interrompu la construction et aucun test de nuit n'a été exécuté pour notre projet. Le chef Q&A n'était pas trop content de cela, et à juste titre.

Naftuli Kay · Answer

Exécutez vos tests unitaires sur lesquels vous avez travaillé si diligemment. Le vert est bon.

Rune Aamodt · Answer

Assurez-vous que votre code est correctement formaté (par exemple pour Java: sélectionnez votre code et appuyez sur Ctrl-Maj-F dans Eclipse). Mais soyez prudent en faisant de même pour un document entier.

Sparky · Answer

Nous faisons ce qui suit ...

Test - Nous voulons nous assurer que cela fonctionne. À tout le moins, nous voulons savoir que cela ne casse rien.
Revue de code, ou au moins une vérification de copain - C'est un excellent moyen de s'assurer que les connaissances sont diffusées et que les gens sont tenus à jour. Il aide également à détecter les bogues avant de procéder à l'archivage.
Envoyer un préavis - Un préavis est envoyé au groupe avant l'enregistrement. Le but n'est pas seulement de faire savoir aux autres quels fichiers ou zones sont en train de changer, mais cela leur donne un avertissement (s'ils choisissent de prendre connaissance) au cas où ces changements devraient les affecter.
Quelques heures après l'envoi de l'avis préalable, l'enregistrement est effectué et le groupe est informé par e-mail. Tout le monde dans le groupe peut savoir quand le travail particulier sur un bug ou une fonctionnalité est terminé.
Une copie de l'avis d'archivage est collée dans l'enregistrement de correctif associé au bogue ou à la fonctionnalité. Lors de la recherche dans les enregistrements, nous constatons qu'il est très pratique d'avoir une idée de ce que la correction/fonctionnalité impliquait.

Jay Bazuzi · Answer

Recherchez les parties de vos modifications qui peuvent entrer en tant qu'unités autonomes.

Souvent, au moment où j'ai un correctif de travail ou une amélioration du code, il y a pas mal de changements. Certains d'entre eux sont spécifiques au changement de comportement que je souhaite; d'autres sont des refactorisations que j'ai faites pour rendre ce changement plus propre.

Je préfère enregistrer chaque refactoring séparément, avec sa propre description de changement, comme ceci:

REFACTORING: Renommer X en Y

X avait du sens auparavant parce que ... mais maintenant il devrait être Y. Ceci est lié au travail pour le problème # 9.

Ensuite, une fois chaque bon refactoring enregistré, le changement de comportement final est souvent trivial.

De plus, certaines modifications affectent de nombreuses lignes de code mais ne sont pas très intéressantes, tandis que d'autres modifications sont très localisées mais ont un impact important. Si ces modifications sont archivées ensemble, il peut être difficile de lire les différences. Donc, je les garde séparés.

Plus tard, quand quelqu'un lit l'histoire du changement, il est évident comment les choses sont arrivées à l'état actuel des choses et pourquoi elles sont ainsi. Il est également trivial d'annuler mon changement de comportement car il n'est pas emmêlé avec des tonnes d'autres modifications.

Paul Nathan · Answer

Je garde un dépôt hg local pour mon travail.

Chaque fois que j'enregistre quelque chose, je regarde le diff et je m'assure que toutes les modifications sont acceptables.
J'essaie de noter la caractéristique clé de l'enregistrement.
J'essaie de garder chaque taille de validation sur une fonctionnalité clé.

Je ne prétends pas que ce sont les meilleurs, mais ils fonctionnent pour moi.

Jason · Answer

Faites ce que vous feriez lorsque vous retournez quelque chose que vous avez emprunté à quelqu'un. Assurez-vous qu'il est propre et en bon état. Si vous avez fait un gâchis, assurez-vous de nettoyer avant de retourner le code à son propriétaire (dans la plupart des cas, votre employeur).

user17815 · Answer

Lorsque j'écris du code dont je sais qu'il n'est pas destiné à être archivé, j'ajoute une ligne avant celle-ci contenant "// TEMP:" et ensuite avec "// END TEMP.". Ceci, en plus de faire un diff avant l'enregistrement, promet que je ne archiverai pas ce code par erreur.

Ken · Answer

Testez soigneusement tout ce que vous avez ajouté ou modifié. Essayez tous les cas possibles auxquels vous pouvez penser. Ne laissez pas les tests au contrôle qualité. Si j'avais un sandwich à chaque fois que j'effectuais des changements mineurs, puis que j'essayais quelques cas de test juste pour être sûr, et que je voyais immédiatement des problèmes, j'aurais beaucoup de sandwichs. Je me dis généralement à voix haute "Je suis vraiment content d'avoir essayé ça ..."

Vous dites que l'interface utilisateur est devenue étrange après votre changement. Si vous n'aviez exécuté que le programme et regardé l'interface utilisateur avant de vous enregistrer, auriez-vous remarqué le problème?