22 votes

Alternative aux binaires dans Subversion

Certains de mes collègues sont convaincus que le fait de commettre construire des objets pour le dépôt subversion est une bonne idée. L'argument est que, de cette manière, l'installation et la mise à jour sur les machines de test est facile - il suffit de "svn up"!

Je suis sûr qu'il y a des arguments de poids contre cette mauvaise pratique, mais tout ce que je peux penser sont boiteux", comme la "il prend plus de place". Quelles sont les meilleures, tueur de raisons de ne pas le faire? Et ce que d'autres approches doivent nous faire d'autre?

C'est pour le code Java si cela fait une différence. Tout est compilé à partir d'Eclipse (sans automatisé de la PDE construit).

Quand je dis ajouter la génération des artefacts, je veux dire un commit devrait ressembler à ceci:

"Added the new Whizbang feature"

 M src/foo/bar/Foo.java
 M bin/Foo.jar

Chaque changement de code a le même fichier jar généré.

23voto

Homes2001 Points 569

À mon avis, le dépôt de code ne doit contenir que du code source ainsi que des bibliothèques tierces requises pour compiler ce code source (qui est aussi le tiers des bibliothèques peut être récupéré avec une certaine dépendance de l'outil de gestion au cours du processus de construction). Les binaires ne devrait pas obtenir vérifié dans le code source.

Je pense que le problème dans votre cas, c'est que vous n'avez pas de bonne scripts de génération en place. C'est pourquoi la construction d'une binaire à partir des sources implique un peu de travail, comme le démarrage d'eclipse, l'importation du projet, le réglage de classpathes, etc...

Si il y a des scripts de génération en place, d'obtenir les fichiers binaires peut être fait avec une commande comme:

svn update; ant dist

Je pense que le plus important de raison de ne pas archiver les fichiers binaires avec la source est la taille de votre référentiel. Ce sera la cause de:

  • Répertoire plus grand et peut-être trop peu d'espace sur le système de contrôle de version serveur
  • Beaucoup de circulation entre le système de gestion de versions serveur et les clients
  • Plus de mise à jour des temps (imaginez-vous faire un SVN update à partir de l'internet...)

Une autre raison pourrait être:

  • Le code Source est facilement comparable, donc beaucoup de caractéristiques d'un système de gestion de versions ne font sens. Mais vous ne pouvez pas comparer facilement les fichiers binaires...

Aussi votre approche décrite ci-dessus présente une surcharge importante à mon avis. Que faire si un développeur oublie de mettre à jour correspond un fichier jar?

15voto

gbjbaanb Points 31045

Tout d'abord, la Subversion (et tous les autres de nos jours) ne sont pas de contrôle de code source gestionnaires (j'ai toujours pensé que les moyens SCM Logiciel de Gestion de la Configuration), mais les systèmes de contrôle de version. Cela signifie qu'ils stocker les changements les informations que vous stockez dans eux, il n'a pas à être le code source, il pourrait être des fichiers image, des ressources bitmap, les fichiers de configuration (texte ou xml), toutes sortes de choses. Il y a seulement 1 pourquoi construit binaires ne devrait pas être considérée comme faisant partie de cette liste, et c'est parce que vous pouvez reconstruire.

Cependant, pensez à pourquoi vous souhaitez stocker la sortie binaires là.

Tout d'abord, c'est un système pour vous aider, pas pour vous dire comment vous devez construire vos applications. Faire le travail à l'ordinateur pour vous plutôt que contre vous. De sorte que si le stockage de fichiers binaires prend de la place, - vous avez des centaines de giga-octets d'espace disque et super rapide réseaux. Ce n'est pas un gros problème pour stocker des objets binaires en plus là (alors qu'il y a dix ans, il aurait été un problème - c'est peut-être pourquoi les gens pensent de binaires dans SCM comme une mauvaise pratique).

Deuxièmement, en tant que développeur, vous pourriez être à l'aise avec l'utilisation du système pour reconstruire n'importe quelle version d'une application, mais les autres qui pourraient s'en servir (par exemple, qa, test, support) ne pourrait pas. Cela signifie que vous auriez besoin d'un système alternatif pour stocker les fichiers binaires, et vraiment, vous avez déjà un système de son de votre SCM! En faire usage.

Troisièmement, vous supposez que vous pouvez reconstruire à partir de la source. Évidemment, vous stockez l'intégralité du code source dedans, mais vous ne stockez pas le compilateur, les bibliothèques, les kits de développement, et tous les autres dépendants de bits requis. Ce qui se passe quand quelqu'un arrive et demande "pouvez-vous me construire la version que nous avons expédié il y a 2 ans, un client a un problème avec cette version". 2 ans c'est une éternité de nos jours, avez-vous même pas le même compilateur que vous avez utilisé à l'époque? Ce qui se passe quand vous vérifiez tous les source pour constater que la nouvelle mise à jour du sdk est incompatible avec votre source et échoue avec des erreurs? Ne vous essuyez votre zone de développement et la réinstallation de toutes les dépendances, il suffit de construire cette application? Pouvez-vous même rappelez-vous que toutes les dépendances ont été?!

Le dernier point est le plus gros, pour enregistrer quelques k de l'espace disque, vous pouvez vous-même le coût des jours, voir des semaines de douleur. (Sod et de la loi indique également que quel que soit l'application que vous devez à la reconstruction sera celui qui exige le plus obscur, difficile à mettre en place la dépendance que vous avez toujours heureux de se débarrasser de)

Afin de stocker les fichiers binaires dans votre SCM, ne vous inquiétez pas sur les banalités.

PS. de nous coller tous les fichiers binaires dans leur "libération" répertoire par projet, puis lorsque l'on veut mettre à jour une machine, nous utilisons des "setup", projet qui consiste en rien d'autre, mais la propriété svn:externals. Vous exportez le projet d'installation et vous êtes fait comme il récupère les bonnes choses et de les placer dans le bon répertoire de la structure.

6voto

CoverosGene Points 3294

Un serveur d'intégration continue comme Hudson aurait la possibilité d'archiver construire des artefacts. Il n'aide pas votre argument "pourquoi pas", mais au moins c'est une alternative.

5voto

Juliano Points 13802

Je suis sûr qu'il y a des arguments de poids contre cette mauvaise pratique

Vous avez la mauvaise présomption que le fait de commettre "construire des artefacts" pour le contrôle de version est une mauvaise idée (sauf si vous avez tort formulé votre question). Il n'est pas.

Il est ok, et en effet très important, de garder ce que vous appelez "construire des artefacts" dans le contrôle de version. De plus, vous devez aussi garder les compilateurs et rien d'autre a utilisé pour transformer l'ensemble des fichiers source pour un produit fini.

Dans les cinq ans à partir de maintenant, vous allez certainement être à l'aide de différents compilateurs et les environnements de build différent, qui peut arriver de ne pas être en mesure de compiler la version d'aujourd'hui de votre projet, pour quelque raison que ce soit. Ce pourrait être une simple petite modification pour corriger un bug dans une version antérieure, va se transformer en un cauchemar de portage que l'ancien logiciel de compilateurs gcc et de construire des outils, il suffit de recompiler un fichier source qui a eu une modification d'une ligne.

Donc, il n'y a pas de raison, vous devez être tellement peur de stockage de construire "artefacts" dans le contrôle de version. Ce que vous pouvez faire est de les conserver dans des lieux séparés.

Je suggère de les séparer, comme:

 ProjectName
 |--- /trunk
 |    |--- /build
 |    |    |--- /bin        <-- compilers go here
 |    |    |--- /lib        <-- libraries (*.dll, *.jar) go here
 |    |    '--- /object     <-- object files (*.class, *.jar) go here
 |    '--- /source          <-- sources (*.java) go here
 |         |--- package1    <-- sources (*.java) go here
 |         |--- package2    <-- sources (*.java) go here

Vous devez configurer votre IDE ou vos scripts de construction à la place de l'objet des fichiers dans /Nom_projet/trunk/build/objet (peut-être même de recréer la structure de répertoire sous .../source).

De cette façon, vous donner à vos utilisateurs la possibilité pour la caisse soit /Nom_projet/coffre pour obtenir la totalité de l'environnement des bâtiments, ou /Nom_projet/trunk/source pour obtenir le code source de l'application.

Dans ../build/bin et ../build/lib, vous devez placer les compilateurs et bibliothèques qui ont été utilisées pour compiler le produit final, ceux utilisés pour expédier le logiciel à l'utilisateur. Dans 5 ou 10 ans, vous allez avoir là, disponibles pour votre utilisation dans certains cas.

5voto

VonC Points 414372

"s'engager à construire des artefacts pour le dépôt subversion" peut être une bonne idée si vous savez pourquoi.

C'est une bonne idée pour une libération de gestion , plus particulièrement pour:

1/ problème d'Emballage

Si une construction artefact n'est pas juste un exe (ou une dll ou un...), mais aussi:

  • certains fichiers de configuration
  • certains scripts pour démarrer/arrêter/redémarrer votre artefact
  • certains sql pour mettre à jour votre base de données
  • certaines sources (compressé dans un fichier) pour faciliter le débogage
  • de la documentation (javadoc compressé dans un fichier)

puis c'est une bonne idée d'avoir un artefact et tous ceux qui sont associés à des fichiers stockés dans un CV.
(Parce qu'il n'est plus juste une question de "re-construction" de l'artefact, mais aussi de "récupération" tous ces fichiers supplémentaires qui feront que l'artefact exécuter)

2/ problème de Déploiement

Supposons que vous avez besoin de déployer de nombreux artefacts dans différents environnements (test, d'homologation, de pré-production, production).
Si:

  • vous produisez de nombreux construire des artefacts
  • ces artefacts sont assez longs pour recréer à partir de zéro

ensuite, ceux-ci ayant des artefacts dans un VCS est une bonne idée, pour éviter de recréer eux.
Vous pouvez seulement de la requête de l'environnement à l'environnement.

Mais vous devez vous rappeler:

  • 1/ vous ne pouvez pas stocker tous les artefacts que vous faites dans la VCS: tous les intermédiaires construire que vous faites pour l'intégration continue, le but doivent pas être stockées dans le VCS (ou vous vous retrouvez avec un énorme espace de stockage avec de nombreux inutile versions des fichiers binaires).
    Seules les versions nécessaires pour l'homologation et à des fins de production doivent être référencés.
    Pour les construire, vous avez besoin d'un référentiel externe (maven ou un répertoire partagé) afin de publier/test rapidement ces versions.

  • 2/ vous ne devriez pas les stocker dans le même Référentiel Subversion, depuis votre développement s'est engagé (numéro de révision) beaucoup plus souvent que votre partenaire se construit (ceux jugés dignes d'homologation et de production de déploiement)
    Cela signifie que les objets stockés dans le second référentiel doit avoir une convention de nommage pour le tag (ou une propriété) afin de retrouver facilement le numéro de révision de l'élaboration à partir de laquelle ils ont été construits.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X