Quelle partie de votre projet devrait être dans le contrôle de code source?

Un collègue développeur a commencé à travailler sur un nouveau projet Drupal, et l'administrateur système a suggéré de ne placer que le sous-répertoire sites / default dans le contrôle de code source, car cela "rendra les mises à jour faciles à écrire par script". Mis à part cette affirmation quelque peu douteuse, cela soulève une autre question: quels fichiers doivent être sous contrôle de source? Et existe-t-il une situation dans laquelle un grand nombre de fichiers devrait être exclu?

Mon opinion est que tout l'arborescence du projet devrait être sous contrôle, ce qui serait le cas d'un projet Drupal, de rails ou de toute autre chose. Cela semble être une évidence - vous avez clairement besoin de la gestion de version pour votre framework autant que pour tout code personnalisé que vous écrivez.

Cela dit, j'aimerais avoir d'autres opinions à ce sujet. Existe-t-il des arguments pour ne pas tout contrôler?

Je dirais que le contrôle source doit contenir au minimum tous les fichiers nécessaires pour recréer une version en cours d'exécution du projet. Cela inclut même les fichiers DDL pour configurer et modifier n’importe quel schéma de base de données, ainsi que dans le bon ordre. Bien entendu, moins les outils nécessaires à la construction et à l’exécution du projet, ainsi que tout ce qui peut être automatiquement dérivé / généré à partir d’autres fichiers du contrôle de source (tels que les fichiers JavaDoc générés à partir des fichiers Java du contrôle de source).

Il est préférable de mettre à peu près tout sous le soleil dans le contrôle de la source.

• Code

• Bibliothèques

• Ressources

• Construire / déployer des scripts

• Création de base de données et scripts de mise à jour

• Certaine documentation

• Fichiers de configuration spécifiques à l'environnement

La seule chose qui ne devrait pas être insérée dans le contrôle de source est la construction d'artefacts pour votre projet.

Je dirais que;

• tout fichier nécessaire à la compilation entre dans le contrôle de version
• aucun fichier (qui peut être) généré par la construction ne

J'aurais tendance à placer des fichiers binaires volumineux tels que des packages d'installation d'outils en dehors du tronc, mais ils devraient toujours être sous contrôle de version.

Et n'oubliez pas de mettre également tout le code de la base de données dans le contrôle de code source! Cela inclut les scripts originaux de création, les scripts pour modifier les tables (marqués par la version du logiciel qui les utilise, afin que vous puissiez recréer toute version de la base de données pour n’importe quelle version des applications), ainsi que des scripts pour renseigner les tables de recherche.

Une expérience difficile à gagner m'a appris que presque tout est dans le contrôle de source. (Mes commentaires ici sont marqués par une décennie et demie de développement pour les systèmes embarqués / de télécommunication sur du matériel propriétaire avec des outils propriétaires, et parfois difficiles à trouver.)

Certaines réponses disent "ne placez pas les fichiers binaires dans le contrôle de source". C'est faux. Lorsque vous travaillez sur un produit avec beaucoup de code tiers et beaucoup de bibliothèques binaires de fournisseurs, vous archivez les bibliothèques binaires . En effet, si vous ne le faites pas, vous devrez procéder à une mise à niveau et vous rencontrerez des problèmes: la version est interrompue car la machine de génération ne dispose pas de la dernière version; quelqu'un donne au nouveau gars les vieux CD à installer; le wiki du projet contient des instructions obsolètes concernant la version à installer; Pire encore, si vous devez travailler en étroite collaboration avec le fournisseur pour résoudre un problème particulier et qu’il vous envoie cinq ensembles de bibliothèques par semaine, vous devez:être capable de suivre quel ensemble de binaires a présenté quel comportement. Le système de contrôle de source est un outil qui résout exactement ce problème.

Certaines réponses disent "ne mettez pas la chaîne d’outils dans le contrôle de source". Je ne dirai pas que c'est faux, mais il est préférable de placer la chaîne d'outils dans le contrôle de source, à moins que vous ne disposiez d'un système de gestion de configuration (CM) extrêmement solide . Encore une fois, considérez le problème de mise à niveau mentionné ci-dessus. Pire encore, j’ai travaillé sur un projet dans lequel quatre types de chaînes d’outils distincts flottaient lorsque j’ai été embauché - tous étant utilisés activement ! L'une des premières choses que j'ai faites (après avoir réussi à faire en sorte que la compilation fonctionne) a été de mettre la chaîne d'outils sous contrôle de code source. (L'idée d'un système CM solide était au-delà de tout espoir.)

Et que se passe-t-il lorsque différents projets nécessitent différentes chaînes d'outils? Exemple: après quelques années, l'un des projets a été mis à niveau par un fournisseur et tous les fichiers Makefiles sont tombés en panne. Il s'avère qu'ils utilisaient une version plus récente de GNU make. Donc nous avons tous mis à jour. Oups, les Makefiles d'un autre projet sont tous tombés en panne. Leçon: validez les deux versions de GNU make et exécutez la version fournie avec votre extraction de projet.

Ou, si vous travaillez dans un endroit où tout le reste est incontrôlable, vous avez des conversations du type "Hé, le nouveau commence aujourd'hui, où est le CD pour le compilateur?" "Dunno, je ne les ai pas vus depuis que Jack a démissionné, il était le gardien des CD." "Euh, n'est-ce pas avant que nous montions du 2e étage?" "Peut-être qu'ils sont dans une boîte ou quelque chose." Et comme les outils ont trois ans, il n’ya aucun espoir de récupérer le vieux CD du vendeur.

Tous vos scripts de construction appartiennent au contrôle de source. Tout! Jusqu'aux variables d'environnement. Votre machine de génération devrait pouvoir exécuter la construction de n’importe lequel de vos projets en exécutant un seul script à la racine du projet. ( ./buildest un standard raisonnable; ./configure; makepresque aussi bon.) Le script doit configurer l'environnement selon les besoins, puis lancer n'importe quel outil permettant de créer le produit (marque, ant, etc.).

Si vous pensez que c'est trop de travail, ce n'est pas. Cela économise en réalité une tonne de travail. Vous validez les fichiers une fois au début, puis à chaque mise à niveau. Aucun loup solitaire ne peut mettre à niveau sa propre machine et valider un paquet de code source qui dépend de la dernière version d'un outil, ce qui en brise la construction pour tout le monde. Lorsque vous engagez de nouveaux développeurs, vous pouvez leur demander de consulter le projet et de l'exécuter ./build. Lorsque la version 1.8 dispose de nombreux réglages de performances et que vous modifiez le code, les indicateurs de compilateur et les variables d'environnement, vous voulez vous assurer que les nouveaux indicateurs de compilateur ne sont pas appliqués accidentellement aux versions de correctifs de la version 1.7, car ils ont réellement besoin du code. changements qui vont avec ou que vous voyez des conditions de course poilues.

Mieux encore , cela vous épargnera un jour: imaginez que vous expédiez la version 3.0.2 de votre produit un lundi. Hourra, célébrer. Mardi matin, un client VIP appelle la ligne d'assistance, se plaignant de ce bogue urgent et supercritique de la version 2.2.6 que vous avez envoyé il y a 18 mois . Et vous devez toujours le prendre en charge contractuellement, et ils refusent toute mise à niveau jusqu'à ce que vous puissiez confirmer avec certitude que le bogue est corrigé dans le nouveau code et qu'ils sont suffisamment volumineux pour vous faire danser. Il y a deux univers parallèles:

• Dans l'univers où vous ne disposez ni de bibliothèques, ni d'outils, ni de scripts de génération dans le contrôle de code source, ni de système CM solide comme le roc ... Vous pouvez vérifier la bonne version du code, mais cela donne vous toutes sortes d'erreurs lorsque vous essayez de construire. Voyons, avons-nous mis à jour les outils en mai? Non, c'étaient les bibliothèques. Ok, retournez dans les anciennes bibliothèques - attendez, y a-t-il eu deux mises à jour? Ah oui, ça a l'air un peu mieux. Mais maintenant, cet étrange crash de l'éditeur de liens semble familier. Oh, c'est parce que les anciennes bibliothèques ne fonctionnaient pas avec la nouvelle chaîne d'outils, c'est pourquoi nous avons dû mettre à niveau, n'est-ce pas? (Je vous épargne l'agonie du reste de l'effort. Cela prend deux semaines et personne n'est heureux à la fin, pas vous, ni la direction, ni le client.)

• Dans l'univers où tout est dans le contrôle de code source, vérifiez la balise 2.2.6, préparez une version de débogage dans une heure environ, passez un jour ou deux à recréer le "bogue VIP", recherchez la cause, corrigez le problème. la version actuelle et convaincre le client de procéder à la mise à niveau. Stressant, mais pas aussi mauvais que cet autre univers où la racine des cheveux est 3 cm plus haute.

Cela dit, vous pouvez aller trop loin:

• Vous devez avoir un système d’exploitation standard dont vous avez une "copie d’or". Documentez, probablement dans un README qui est en contrôle de code source, afin que les générations futures sachent que la version 2.2.6 et les versions antérieures ne construit sur RHEL 5.3 et 2.3.0 et plus tard seulement construit sur Ubuntu 11.04. S'il est plus facile pour vous de gérer les outils de cette façon, allez-y, assurez-vous simplement qu'il s'agit d'un système fiable.
• La documentation du projet est difficile à maintenir dans un système de contrôle de source. Les documents de projet ont toujours une longueur d'avance sur le code lui-même et il n'est pas rare de travailler sur la documentation de la prochaine version tout en travaillant sur le code de la version actuelle. Surtout si tous vos documents de projet sont des documents binaires que vous ne pouvez pas différencier ou fusionner.
• Si vous avez un système qui contrôle les versions de tout ce qui est utilisé dans la construction, utilisez-le ! Assurez-vous simplement qu'il est facile de synchroniser l'ensemble de l'équipe, de sorte que tout le monde (y compris la machine de compilation) tire du même ensemble d'outils. (Je pense à des systèmes tels que pbuilder de Debian et à une utilisation responsable de virtualenv de python.)

Les seules choses que je ne mets pas sous contrôle de code source sont des fichiers que vous pouvez facilement régénérer ou qui sont spécifiques au développeur. Cela signifie que les exécutables et les fichiers binaires sont composés de votre code source, de la documentation générée à partir de la lecture / analyse de fichiers sous contrôle de code source et de fichiers spécifiques à l'EDI. Tout le reste entre dans le contrôle de version et est géré de manière appropriée.

Le cas d'utilisation du contrôle de source est le suivant: Et si toutes les machines de nos développeurs et toutes nos machines de déploiement étaient touchées par un météore? Vous voulez que la récupération soit aussi proche que possible de la caisse et de la construction. (Si c'est trop bête, vous pouvez choisir "engager un nouveau développeur".)

En d'autres termes, tous les éléments, à l'exception des systèmes d'exploitation, des applications et des outils, doivent figurer dans VCS et dans les systèmes intégrés, où il peut exister une dépendance à une version binaire d'un outil spécifique. J'ai également vu les outils conservés dans VCS!

Le contrôle de la source incomplet est l’un des risques les plus courants que je vois lors de la consultation: il ya toutes sortes de frictions associées à l’embauche d’un nouveau développeur ou à la configuration d’une nouvelle machine. En plus des concepts d'intégration continue et de livraison continue, vous devez avoir une idée du "développement continu" - un informaticien peut-il configurer une nouvelle machine de développement ou de déploiement de manière essentiellement automatique, de sorte que le développeur puisse consulter le code avant la fin leur première tasse de café?

Tout ce qui contribue au projet et pour lequel vous souhaitez suivre les modifications.

Les exceptions peuvent inclure de grands blobs binaires tels que des images, si vous utilisez une scm qui ne gère pas très bien les données binaires.

Drupal utilise git, je vais donc utiliser la terminologie de git. J'utiliserais subrepos pour chaque module afin de pouvoir extraire les mises à jour de modules du dépôt officiel de Drupal, tout en préservant la structure des déploiements individuels. De cette façon, vous bénéficiez des avantages de la scriptabilité sans perdre les avantages de tout avoir sous le contrôle de la source.

Tout doit être sous contrôle de source, sauf:

• Les fichiers de configuration, s'ils incluent des options de configuration différentes pour chaque développeur et / ou chaque environnement (développement, test, production)
• Mettre les fichiers en cache, si vous utilisez la mise en cache du système de fichiers
• Fichiers journaux, si vous vous connectez à des fichiers texte
• Tout ce qui ressemble aux fichiers de cache et aux fichiers journaux est généré du contenu
• (Très) gros fichiers binaires peu susceptibles de changer (certains systèmes de contrôle de versions ne les aiment pas, mais si vous utilisez hg ou git, cela ne les dérange pas beaucoup)

Pensez-y comme ceci: chaque nouveau membre de l’équipe devrait pouvoir extraire une copie de travail du projet (moins les éléments de configuration).

Et n'oubliez pas de placer également les modifications de schéma de base de données (simples copies SQL de chaque modification de schéma) sous contrôle de version. Vous pouvez inclure la documentation utilisateur et API, si cela a du sens pour le projet.

@maple_shaft soulève un problème important avec ma première déclaration concernant les fichiers de configuration de l'environnement dans les commentaires. J'aimerais préciser que ma réponse concerne les détails de la question, qui concerne les projets Drupal ou CMS génériques. Dans de tels scénarios, vous avez généralement une base de données locale et de production, et une option de configuration d'environnement est les informations d'identification de ces bases de données (et des informations d'identification similaires). Il est conseillé de ne PAS les placer sous contrôle de source, car cela créerait plusieurs problèmes de sécurité.

Dans un flux de travail de développement plus typique, je conviens toutefois avec maple_shaft que les options de configuration d'environnement doivent être sous contrôle de source pour permettre la création et le déploiement en une étape de n'importe quel environnement.

Tout ce que votre génération automatisée génère ne va pas dans le contrôle de source. Tout ce qui ne nécessite aucune modification lors de la génération est utilisé dans le contrôle de source. C'est si simple.

Par exemple, les éléments suivants ne vont pas dans le contrôle de source:

• code généré
• binaires générés
• tout ce qui est créé par votre build
• tout ce qui a été créé au moment de l'exécution par votre service, processus ou application Web

Que fait-on dans le contrôle de code source?

• tout ce qu'un humain crée
• tout élément créé par une autre personne ou un autre groupe (par exemple, une bibliothèque interne tierce où le contrôle de code source est distribué ou les fichiers binaires d'un projet open source).
• Scripts et autres sources qui créent des éléments comme une base de données (comment recréer la base de données si tous les administrateurs de base de données deviennent AWOL).

Ces règles empiriques reposent sur la notion selon laquelle tout ce qui se trouve sous le contrôle de source peut être modifié par un humain et peut prendre du temps précieux à quelqu'un pour comprendre pourquoi il est là.

Tout ce dont vous avez besoin pour travailler et pouvoir changer doit faire l’objet de versions différentes. Mais il est rarement nécessaire que deux systèmes indépendants en assurent le suivi.

Tout ce qui est généré de manière fiable peut généralement être attaché à une version source. Par conséquent, il n’est pas nécessaire de le suivre indépendamment: source générée, fichiers binaires qui ne sont pas transmis d’un système à un autre, etc.

Construisez des bûches et d’autres choses dont probablement personne ne se soucie (mais vous ne le savez jamais avec certitude) sont généralement mieux suivies par celui qui les génère: Jenkins, etc.

Les produits conçus pour passer d'un système à un autre doivent être suivis, mais un dépôt Maven est un bon moyen de le faire. Vous n'avez pas besoin du niveau de contrôle fourni par un contrôle de source. Les livrables sont souvent dans la même catégorie.

Tout ce qui reste (et à ce stade, il ne devrait y avoir qu'un peu plus que les fichiers source et la configuration du serveur), passe dans le contrôle de source.

Ma réponse est assez simple: pas de binaires. Par implication, presque tout le reste.

(Ce ne sont certainement pas des sauvegardes de base de données, des migrations de schéma ou des données utilisateur.)

Le contrôle de source est un mécanisme de suivi des modifications. Utilisez-le quand vous voulez savoir qui a changé quoi et quand.

Le contrôle de source n'est pas libre. Cela ajoute à la complexité de votre flux de travail et nécessite une formation pour les nouveaux collègues. Peser les avantages contre le coût.

Par exemple, il peut être difficile de contrôler les bases de données. Auparavant, nous avions un système dans lequel vous deviez enregistrer manuellement les définitions dans un fichier texte, puis les ajouter au contrôle de source. Cela prenait beaucoup de temps et n'était pas fiable. En raison de son manque de fiabilité, vous ne pouviez pas l'utiliser pour configurer une nouvelle base de données ou pour vérifier à quelle heure une modification avait été effectuée. Mais nous l’avons gardé pendant des années, en perdant un nombre incalculable d’heures, car notre responsable pensait que "tout devrait être sous contrôle de la source".

Le contrôle de la source n'est pas magique. Essayez-le, mais abandonnez-le s'il n'apporte pas assez de valeur pour compenser les coûts.

Choses que je ne mettrais pas dans le contrôle de source:

• Clés secrètes et mots de passe
• Le SDK même s’il s’agit du même répertoire et si je crée un correctif pour le SDK, il devrait en faire un autre projet, car ce serait par framework plutôt que par application.
• Bibliothèques tierces telles que. Restes de migration, sauvegardes, code compilé, code sous une autre licence (éventuellement)

Je ne fais donc pas, hg addremovepar exemple, de créer un nouveau clone de temps en temps lorsque le SDK est mis à jour. Cela me permet également de faire une sauvegarde complète à chaque fois que le SDK est mis à jour et de vérifier qu'une nouvelle version clonée à partir du référentiel fonctionne correctement.

Je vous recommande fortement le livre suivant qui répond à vos préoccupations:

Livraison continue: versions logicielles fiables via l'automatisation de la construction, des tests et du déploiement . Plus précisément, le chapitre 2 traite des éléments à placer dans le contrôle de source, ce qui, comme beaucoup de gens l’ont dit, représente pratiquement tout sauf la plupart du contenu généré à la suite d’une construction.

Je ne suis pas d'accord avec un élément de la réponse acceptée fournie par @FrustratedWithFormsDesigner moins parce qu'il préconise de ne pas placer dans le contrôle de version les outils nécessaires à la construction du projet. Quelque part dans le contrôle de code source (adjacent au code en cours de construction), se trouvent les scripts de construction permettant de générer le projet et les scripts de génération exécutés à partir d'une ligne de commande uniquement. Si, par outils, il entend les IDE et les éditeurs, ils ne devraient pas être obligés de construire le projet, que ce soit. Celles-ci sont utiles pour le développement actif / rapide des développeurs et la configuration de ce type d’environnement peut également être scriptée ou téléchargée à partir d’une autre section de SCM ou d’un type de serveur de gestion binaire. La configuration de tels environnements de développement (IDE) doit être aussi automatisée que possible.

Je ne suis pas non plus d'accord avec ce que @ Yannis Rizos a déclaré sur le placement de configurations pour les environnements dans le contrôle de source. La raison en est que vous devriez être capable de reconstruire n’importe quel environnement à votre guise en n’utilisant que des scripts et que cela n’est pas gérable sans paramètres de configuration dans le contrôle de source. Il n’existe pas non plus d’historique de l’évolution des configurations pour divers environnements sans placer ces informations dans le contrôle de source. À présent, les paramètres de l'environnement de production peuvent être confidentiels ou les entreprises peuvent ne pas vouloir les placer dans le contrôle de version. Une deuxième option consiste donc à les placer dans le contrôle de version afin qu'elles aient un historique et de donner à ce référentiel un accès limité.

Conservez tout le code dans le contrôle de version et toutes les configurations et les données utilisateur. Pour être spécifique à drupal, vous devez tout mettre dans le contrôle de version sauf les fichiers et settings.php