Dois-je stocker le code généré dans le contrôle de code source

C'est un débat auquel je participe. J'aimerais avoir plus d'opinions et de points de vue.

Nous avons des classes qui sont générées au moment de la construction pour gérer les opérations DB (dans ce cas précis, avec SubSonic, mais je ne pense pas que ce soit très important pour la question). La génération est définie comme une étape de pré-génération dans Visual Studio. Ainsi, chaque fois qu'un développeur (ou le processus de construction officiel) exécute une construction, ces classes sont générées, puis compilées dans le projet.

Maintenant, certaines personnes affirment que l'enregistrement de ces classes dans le contrôle de code source pourrait être source de confusion, au cas où le code que vous obtenez ne correspond pas à ce qui aurait été généré dans votre propre environnement.

J'aimerais avoir un moyen de retracer l'historique du code, même s'il est généralement traité comme une boîte noire.

Des arguments ou des contre-arguments?

Je ne sélectionnerai pas de réponse acceptée à ce stade pour les raisons mentionnées ci-dessus.

L'enregistrer dans le contrôle de code source est plus problématique qu'il n'en vaut la peine.

Vous devez faire un commit à chaque fois que vous faites une compilation pour qu'elle ait une valeur quelconque.

En général, nous laissons le code généré (idl, jaxb, etc.) en dehors du contrôle de source où je travaille et cela n'a jamais été un problème

Mettez-le dans le contrôle du code source. L'avantage d'avoir l'historique de tout ce que vous écrivez à la disposition des futurs développeurs l'emporte sur la douleur mineure de la reconstruction occasionnelle après une synchronisation.

Chaque fois que je veux afficher les modifications apportées à une arborescence source sur mon propre dépôt personnel, tous les «fichiers générés» apparaîtront comme ayant changé et doivent être validés.

Je préférerais avoir une liste plus claire des modifications qui n'incluent que les mises à jour réelles qui ont été effectuées, et non les modifications générées automatiquement.

Laissez-les de côté, puis après une compilation, ajoutez un 'ignorer' sur chacun des fichiers générés.

Regardez les choses de cette façon: archivez-vous vos fichiers objets dans le contrôle de code source? Les fichiers source générés sont des artefacts de construction, tout comme les fichiers objets, les bibliothèques et les exécutables. Ils devraient être traités de la même manière. La plupart diront que vous ne devriez pas vérifier les fichiers objets et exécutables générés dans le contrôle de code source. Les mêmes arguments s'appliquent à la source générée.

Si vous avez besoin de regarder la version historique d'un fichier généré, vous pouvez synchroniser avec la version historique de ses sources et reconstruire.

La vérification des fichiers générés de toute sorte dans le contrôle de code source est analogue à la dénormalisation de la base de données. Il y a parfois des raisons de le faire (généralement pour les performances), mais cela ne doit être fait qu'avec beaucoup de soin car il devient beaucoup plus difficile de maintenir l'exactitude et la cohérence une fois que les données sont dénormalisées.

Je dirais que vous devriez éviter d'ajouter du code généré (ou d'autres artefacts) au contrôle de code source. Si le code généré est le même pour l'entrée donnée, vous pouvez simplement vérifier les versions que vous souhaitez différencier et générer le code pour comparaison.

J'appelle le principe DRY. Si vous avez déjà les "fichiers source" dans le référentiel qui sont utilisés pour générer ces fichiers de code au moment de la construction, il n'est pas nécessaire d'avoir le même code validé "deux fois".

De plus, vous pouvez éviter certains problèmes de cette façon si, par exemple, la génération de code s'arrête un jour.

Non, pour trois raisons.

1. Le code source est tout ce qui est nécessaire et suffisant pour reproduire un instantané de votre application à un moment donné ou précédent dans le temps - ni plus ni moins. Une partie de ce que cela implique est que quelqu'un est responsable de tout ce qui est enregistré. En général, je suis heureux d'être responsable du code que j'écris, mais pas du code qui est généré à la suite de ce que j'écris.

2. Je ne veux pas que quelqu'un soit tenté d'essayer de raccourcir une version à partir de sources primaires en utilisant un code intermédiaire qui peut ou non être actuel (et plus important encore dont je ne veux pas accepter la responsabilité.) Et ce n'est pas trop tentant pour certaines personnes de se laisser entraîner dans un processus dénué de sens sur le débogage des conflits dans le code intermédiaire basé sur des constructions partielles.

3. Une fois qu'il est sous contrôle de code source, j'accepte la responsabilité d'un fichier. être là, b. il est courant, et c. il peut être intégré de manière fiable avec tout le reste. Cela inclut le supprimer lorsque je ne l'utilise plus. Moins cette responsabilité est importante, mieux c'est.

Je ne pense vraiment pas que vous devriez les enregistrer.

Il est certain que tout changement dans le code généré sera soit du bruit - des changements entre les environnements, soit des changements à la suite de quelque chose d'autre - par exemple un changement dans votre base de données. Si les scripts de création de votre base de données (ou toute autre dépendance) sont sous contrôle de code source, pourquoi avez-vous également besoin des scripts générés?

La règle générale est non , mais si la génération du code prend du temps (en raison de l'accès à la base de données, des services Web, etc.), vous voudrez peut-être enregistrer une version mise en cache dans le contrôle de source et épargner à tout le monde la douleur.

Vos outils doivent également en être conscients et gérer l'extraction à partir du contrôle de code source lorsque cela est nécessaire, trop d'outils décident de récupérer à partir du contrôle de code source sans aucune raison.
Un bon outil utilisera la version mise en cache sans la toucher (ni modifier les pas de temps sur le fichier).

Vous devez également mettre un gros avertissement dans le code généré pour que les gens ne modifient pas le fichier, un avertissement en haut ne suffit pas, vous devez le répéter toutes les douzaines de lignes.

Nous ne stockons pas non plus le code DB généré: puisqu'il est généré, vous pouvez l'obtenir à volonté dans n'importe quelle version donnée à partir des fichiers source. Le stocker serait comme stocker le bytecode ou autre.

Maintenant, vous devez vous assurer que le générateur de code utilisé dans une version donnée est disponible! Les versions plus récentes peuvent générer du code différent ...

Laisser de côté.

Si vous archivez des fichiers générés, vous faites quelque chose de mal. Quel est le problème peut différer, il se pourrait que votre processus de construction est inefficace, ou autre chose, mais je ne peux pas le voir jamais être une bonne idée. L'historique doit être associé aux fichiers source et non à ceux générés.

Cela crée juste un casse-tête pour les personnes qui finissent par essayer de résoudre les différences, trouvent les fichiers qui ne sont plus générés par la construction, puis les suppriment, etc.

Un monde de douleur attend ceux qui enregistrent les fichiers générés!

Il existe un cas particulier où vous souhaitez archiver vos fichiers générés: lorsque vous devrez peut-être construire sur des systèmes où les outils utilisés pour générer les autres fichiers ne sont pas disponibles. L'exemple classique de ceci, et avec lequel je travaille, est le code Lex et Yacc. Parce que nous développons un système d'exécution qui doit construire et fonctionner sur une grande variété de plates-formes et d'architectures, nous ne pouvons compter que sur les systèmes cibles pour avoir des compilateurs C et C ++, pas les outils nécessaires pour générer le code de lexing / d'analyse pour notre définition d'interface traducteur. Ainsi, lorsque nous changeons nos grammaires, nous archivons le code généré pour l'analyser.

arrivant un peu tard ... en tout cas ...

Souhaitez-vous mettre le fichier intermédiaire du compilateur dans le contrôle de version source? En cas de génération de code, par définition le code source est l'entrée du générateur tandis que le code généré peut être considéré comme des fichiers intermédiaires entre la source "réelle" et l'application construite.

Je dirais donc: ne mettez pas le code généré sous contrôle de version, mais le générateur et son entrée.

Concrètement, je travaille avec un générateur de code que j'ai écrit: je n'ai jamais eu à maintenir le code source généré sous contrôle de version. Je dirais même que puisque le générateur a atteint un certain niveau de maturité, je n'ai pas eu à observer le contenu du code généré bien que l'entrée (par exemple la description du modèle) ait changé.

Dans certains projets, j'ajoute du code généré au contrôle de code source, mais cela dépend vraiment. Ma ligne directrice de base est que si le code généré fait partie intégrante du compilateur, je ne l'ajouterai pas. Si le code généré provient d'un outil externe, tel que SubSonic dans ce cas, je l'ajouterais au contrôle de code source. Si vous mettez régulièrement à niveau le composant, je souhaite connaître les modifications apportées à la source générée en cas de bogue ou de problème.

En ce qui concerne le code généré devant être archivé, le pire des cas consiste à différencier manuellement les fichiers et à restaurer les fichiers si nécessaire. Si vous utilisez svn, vous pouvez ajouter un hook de pré-validation dans svn pour refuser une validation si le fichier n'a pas vraiment changé.

Le travail de gestion de la configuration (dont le contrôle de version n'est qu'une partie) est de pouvoir effectuer les opérations suivantes:

• Sachez quels changements et corrections de bogues ont été apportés à chaque version livrée.
• Être capable de reproduire exactement n'importe quelle version livrée, à partir du code source d'origine. Le code généré automatiquement ne compte pas comme "code source" quelle que soit la langue.

Le premier garantit que lorsque vous dites au client ou à l'utilisateur final "le bogue que vous avez signalé la semaine dernière est corrigé et la nouvelle fonctionnalité a été ajoutée", ils ne reviennent pas deux heures plus tard et disent "non, ce n'est pas le cas". Il s'assure également qu'ils ne disent pas "Pourquoi fait-il X? Nous n'avons jamais demandé X".

Le second signifie que lorsque le client ou l'utilisateur final signale un bogue dans une version que vous avez publiée il y a un an, vous pouvez revenir à cette version, reproduire le bogue, le corriger et prouver que c'était votre correctif a éliminé le bogue plutôt que une certaine perturbation du compilateur et d'autres correctifs.

Cela signifie que votre compilateur, vos bibliothèques, etc. doivent également faire partie de CM.

Alors maintenant, pour répondre à votre question: si vous pouvez faire tout ce qui précède, vous n'avez pas besoin d'enregistrer des représentations intermédiaires, car vous êtes assuré d'obtenir la même réponse de toute façon. Si vous ne pouvez pas faire tout ce qui précède, tous les paris sont ouverts car vous ne pouvez jamais garantir de faire la même chose deux fois et d'obtenir la même réponse. Vous pouvez donc également mettre tous vos fichiers .o sous contrôle de version.

Cela dépend vraiment. Au final, le but est de pouvoir reproduire ce que vous aviez si besoin. Si vous êtes en mesure de régénérer vos binaires exactement, il n'est pas nécessaire de les stocker. mais vous devez vous rappeler que pour recréer votre contenu, vous aurez probablement besoin de la configuration exacte avec laquelle vous l'avez fait en premier lieu, et cela signifie non seulement votre code source, mais aussi votre environnement de construction, votre IDE, peut-être même d'autres bibliothèques , générateurs ou trucs, dans la configuration exacte (versions) que vous avez utilisée.

J'ai rencontré des problèmes dans les projets où nous avons mis à niveau notre environnement de construction vers des versions plus récentes ou même vers un autre fournisseur, où nous n'avons pas pu recréer les binaires exacts que nous avions auparavant. C'est une vraie douleur lorsque les binaires à développer dépendent d'une sorte de hachage, en particulier dans un environnement sécurisé, et que les fichiers recréés diffèrent d'une manière ou d'une autre en raison des mises à niveau du compilateur ou autre.

Alors, voudriez-vous stocker le code généré: je dirais non. Les binaires ou les livrables publiés, y compris les outils avec lesquels vous les avez reproduits, je les stockerais. Et puis, il n'est pas nécessaire de les stocker dans le contrôle de code source, faites simplement une bonne sauvegarde de ces fichiers.

La bonne réponse est "ça dépend". Cela dépend des besoins du client. Si vous pouvez restaurer le code vers une version particulière et résister à tout audit externe sans elle, vous n'êtes toujours pas sur des bases solides. En tant que développeurs, nous devons tenir compte non seulement du «bruit», de la douleur et de l'espace disque, mais aussi du fait que nous sommes chargés de générer la propriété intellectuelle et qu'il peut y avoir des ramifications juridiques. Seriez-vous en mesure de prouver à un juge que vous êtes en mesure de régénérer un site Web exactement comme un client l'a vu il y a deux ans?

Je ne vous suggère pas de sauvegarder ou de ne pas enregistrer les fichiers générés, quelle que soit la manière dont vous décidez si vous n'impliquez pas les experts en la matière de la décision que vous avez probablement tort.

Mes deux centimes.

Il y a de bons arguments pour et contre présentés ici. Pour mémoire, je construis le système de génération T4 dans Visual Studio et notre option par défaut prête à l'emploi provoque l'archivage du code généré. Vous devez travailler un peu plus si vous préférez ne pas vous enregistrer.

Pour moi, la considération clé est de faire varier la sortie générée lorsque l'entrée ou le générateur lui-même est mis à jour.

Si votre sortie n'est pas archivée, vous devez alors prendre une copie de tout le code généré avant de mettre à niveau un générateur ou de modifier une entrée afin de pouvoir comparer cela avec la sortie de la nouvelle version. Je pense que c'est un processus assez fastidieux, mais avec la sortie archivée, il suffit de comparer la nouvelle sortie au référentiel.

À ce stade, il est raisonnable de se demander "Pourquoi vous souciez-vous des changements dans le code généré?" (Surtout par rapport au code objet.) Je crois qu'il y a quelques raisons principales, qui se résument à l'état actuel de la technique plutôt qu'à un problème inhérent.

1. Vous créez du code manuscrit qui s'intègre étroitement au code généré. Ce n'est pas le cas dans l'ensemble des fichiers obj de nos jours. Lorsque le code généré change, il est malheureusement assez fréquent que certains codes manuscrits doivent changer pour correspondre. Les gens n'observent souvent pas un degré élevé de compatibilité ascendante avec les points d'extensibilité dans le code généré.

2. Le code généré change simplement son comportement. Vous ne toléreriez pas cela de la part d'un compilateur, mais pour être honnête, un générateur de code au niveau de l'application cible un domaine de problème différent avec une plus large gamme de solutions acceptables. Il est important de voir si les hypothèses que vous avez faites sur le comportement précédent sont maintenant rompues.

3. Vous ne faites tout simplement pas confiance à 100% à la sortie de votre générateur d'une version à l'autre. Les outils générateurs ont beaucoup de valeur, même s'ils ne sont pas construits et maintenus avec la rigueur de votre fournisseur de compilateur. La version 1.0 a peut-être été parfaitement stable pour votre application, mais peut-être que la version 1.1 présente maintenant quelques problèmes pour votre cas d'utilisation. Sinon, vous modifiez les valeurs d'entrée et constatez que vous exercez une nouvelle partie du générateur que vous n'aviez pas utilisée auparavant - vous risquez d'être surpris par les résultats.

Essentiellement, tout cela dépend de la maturité des outils - la plupart des générateurs de code d'applications d'entreprise ne sont pas proches du niveau des compilateurs ou même des outils de niveau lex / yacc depuis des années.

Les deux parties ont des arguments valables et raisonnables, et il est difficile de s'entendre sur quelque chose de commun. Les systèmes de contrôle de version (VCS) suivent les fichiers que les développeurs y ont placés et supposent que les fichiers à l'intérieur du VCS sont fabriqués à la main par les développeurs, et les développeurs sont intéressés par l'historique et le changement entre toute révision des fichiers. Cette hypothèse égalise les deux concepts, "Je veux obtenir ce fichier lorsque je passe à la caisse". et "Je suis intéressé par la modification de ce fichier."

Maintenant, les arguments des deux côtés pourraient être reformulés comme ceci:

• "Je souhaite récupérer tous ces fichiers générés lors de l'extraction, car je n'ai pas l'outil pour les générer dans cette machine."
• "Je ne devrais pas les mettre dans VCS, car je ne suis pas intéressé par la modification de ce fichier."

Heureusement, il semble que les deux exigences ne soient pas fondamentalement contradictoires. Avec une certaine extension des VCS actuels, il devrait être possible d'avoir les deux. En d'autres termes, c'est un faux dilemme. Si nous réfléchissons un peu, il n'est pas difficile de se rendre compte que le problème découle de l'hypothèse que les VCS tiennent. Les VCS doivent distinguer les fichiers, qui sont fabriqués à la main par les développeurs, des fichiers qui ne sont pas fabriqués à la main par les développeurs, mais qui se trouvent juste à l'intérieur de ce VCS. Pour la première catégorie de fichiers, que nous appelons généralement les fichiers source (code), les VCS ont fait un excellent travail maintenant. Pour cette dernière catégorie, les VCS n'ont pas encore eu un tel concept, pour autant que je sache.

Résumé

Je prendrai git comme exemple pour illustrer ce que je veux dire.

• git status ne doit pas afficher les fichiers générés par défaut.
• git commit doit inclure les fichiers générés en tant qu'instantané.
• git diff ne doit pas afficher les fichiers générés par défaut.

PS

Les hooks Git pourraient être utilisés comme solution de contournement, mais ce serait génial si git le prend en charge nativement. gitignorene répond pas à nos exigences, car les fichiers ignorés n'iront pas dans les VCS.enter code here

Je plaiderais pour. Si vous utilisez un processus d'intégration continue qui vérifie le code, modifie le numéro de version, construit le logiciel puis le teste, il est alors plus simple et plus facile de simplement avoir ce code dans votre référentiel.

De plus, cela fait partie intégrante de chaque «instantané» que vous prenez de votre référentiel logiciel. Si cela fait partie du logiciel, alors il devrait faire partie du référentiel.

Je dirais que oui, vous voulez le mettre sous contrôle de source. Du point de vue de la gestion de la configuration, TOUT ce qui est utilisé pour produire une version logicielle doit être contrôlé afin de pouvoir être recréé. Je comprends que le code généré peut facilement être recréé, mais on peut faire valoir que ce n'est pas le même puisque la date / les horodatages seront différents entre les deux versions. Dans certains domaines comme le gouvernement, ils exigent souvent que ce soit ce qui est fait.

En général, le code généré n'a pas besoin d'être stocké dans le contrôle de code source car l'historique des révisions de ce code peut être retracé par l'historique des révisions du code qui l'a généré!

Cependant, il semble que l'OP utilise le code généré comme couche d'accès aux données de l'application au lieu d'en écrire une manuellement. Dans ce cas, je modifierais le processus de construction et validerais le code dans le contrôle de code source car il s'agit d'un composant critique du code d'exécution. Cela supprime également la dépendance sur l'outil de génération de code du processus de construction au cas où les développeurs auraient besoin d'utiliser une version différente de l'outil pour différentes branches.

Il semble que le code ne doit être généré qu'une seule fois au lieu de chaque build. Lorsqu'un développeur doit ajouter / supprimer / modifier la façon dont un objet accède à la base de données, le code doit être généré à nouveau, tout comme pour des modifications manuelles. Cela accélère le processus de construction, permet d'effectuer des optimisations manuelles sur la couche d'accès aux données et l'historique de la couche d'accès aux données est conservé de manière simple.

Je finis (malheureusement) par mettre beaucoup de sources dérivées sous le contrôle de la source parce que je travaille à distance avec des personnes qui ne peuvent pas être dérangées pour mettre en place un environnement de construction approprié ou qui n'ont pas les compétences pour le configurer afin que le les sources dérivées sont construites exactement comme il faut. (Et en ce qui concerne les autotools de Gnu, je suis moi-même l'une de ces personnes! Je ne peux pas travailler avec trois systèmes différents, chacun fonctionnant avec une version différente des autotools - et uniquement cette version.)

Ce type de difficulté s'applique probablement plus aux projets à temps partiel, bénévoles et open-source qu'aux projets payants où la personne qui paie les factures peut insister sur un environnement de construction uniforme.

Lorsque vous faites cela, vous vous engagez essentiellement à créer les fichiers dérivés uniquement sur un site ou uniquement sur des sites correctement configurés. Vos Makefiles (ou autre) doivent être configurés pour remarquer où ils s'exécutent et doivent refuser de rediriger les sources à moins qu'ils ne sachent qu'ils fonctionnent sur un site de construction sûr.

S'il fait partie du code source, il doit être placé sous contrôle de code source indépendamment de qui ou de ce qui le génère. Vous voulez que votre contrôle de source reflète l'état actuel de votre système sans avoir à le régénérer.

Ayez absolument le code généré dans le contrôle de code source, pour de nombreuses raisons. Je répète ce que beaucoup de gens ont déjà dit, mais certaines raisons pour lesquelles je le ferais sont

1. Avec les fichiers de code dans le contrôle de code source, vous pourrez potentiellement compiler le code sans utiliser votre étape de pré-génération Visual Studio.
2. Lorsque vous effectuez une comparaison complète entre deux versions, il serait bon de savoir si le code généré a changé entre ces deux balises, sans avoir à le vérifier manuellement.
3. Si le générateur de code lui-même change, vous voudrez vous assurer que les modifications apportées au code généré changent de manière appropriée. c'est-à-dire si votre générateur change, mais que la sortie n'est pas censée changer, alors lorsque vous allez valider votre code, il n'y aura aucune différence entre ce qui a été précédemment généré et ce qui est dans le code généré maintenant.

Je laisserais les fichiers générés hors d'une arborescence source, mais je les mettrais dans une arborescence de construction séparée.

par exemple, le flux de travail est

1. archiver / sortir / modifier / fusionner la source normalement (sans aucun fichier généré)
2. Aux occasions appropriées, extrayez l'arborescence des sources dans un arbre de construction propre
3. Après une compilation, archivez tous les fichiers "importants" (fichiers sources "réels", exécutables + fichier source généré) qui doivent être présents à des fins d'audit / réglementaires. Cela vous donne un historique de tout le code généré approprié + exécutables + quoi que ce soit, à des incréments de temps liés aux versions / tests d'instantanés, etc. et découplés du développement quotidien.

Il y a probablement de bons moyens dans Subversion / Mercurial / Git / etc de lier l'historique des vrais fichiers source aux deux endroits.

On dirait qu'il y a des opinions très fortes et convaincantes des deux côtés. Je recommanderais de lire toutes les réponses les plus votées, puis de décider quels arguments s'appliquent à votre cas spécifique.

MISE À JOUR: J'ai posé cette question car je croyais vraiment qu'il y avait une réponse définitive. En regardant toutes les réponses, je pourrais dire avec un haut niveau de certitude, qu'il n'y a pas de telle réponse. La décision doit être prise en fonction de plus d'un paramètre. La lecture des autres réponses pourrait fournir une très bonne indication des types de questions que vous devriez vous poser lorsque vous devez vous prononcer sur cette question.