Quels arguments peuvent être utilisés contre l'utilisation de fichiers zip de code source sous forme de contrôle de la version?
En général, chaque développeur travaille sur leur propre programme et en a une responsabilité. Mais il y a bien sûr des moments où d'autres développeurs sont impliqués dans le travail sur ce programme.
Chaque développeur a sa propre convention de dénomination pour les fichiers ZIP allant de l'ajout de la date, un nombre après le nom du programme ou même l'adhésion _OLD / _Lold _newversion, etc ... lorsqu'il y a collaboration sur le développement de certains codes. Il doit être vérifié qui a la "dernière" version du code - et où elle réside, généralement la version correcte est identifiée.
Il n'y a pas de méthode existante facile à diffuser des arbres source et pendant le développement des changements indésirables glisser occasionnellement dans le code.
Le fichier zip correspondant aux communiqués de logiciels qui ont une libération à la fabrication sont archivés. Cela ajoute au moins une certaine traçabilité.
Également avant la RTM, le code est examiné par pair contre la version précédemment publiée afin que l'assurance qualité existe.
Y a-t-il des papiers blancs formels expliquant les avantages du contrôle de la source, ce qui précise que ce qui précède n'est pas une forme de contrôle de source entièrement valide? Des arguments existent ici que, depuis le contrôle du produit final (versions de fabrication) sous contrôle et qui sont examinés qu'il n'y a pas de problème avec le processus. Les développeurs n'ont pas trop de problème de travail avec des fichiers zip de cette manière, mais ne peuvent pas être au courant des avantages.
15 Réponses :
Le meilleur argument est sûrement que l'utilisation d'un système de contrôle de version comme Subversion ou Mercurial est beaucoup plus facile, beaucoup plus facile et plus sûr que de gâcher avec des fichiers ZIP. Je doute qu'il y ait eu beaucoup d'écriture de papier sur le sujet, comme l'utilisation de Les fichiers zip à cet effet sont assez évidemment faux.
Il y a un certain nombre de questions sur les avantages généraux du contrôle de la version. Par exemple Comment puis-je convaincre mon département? Pour implémenter un système de contrôle de version? et https://stackoverflow.com/ QUESTIONS / 250984 / DO-I-VRAIMENT-BESOIN-VERSION-CONTRÔLE
Je ne reçois pas l'argument le plus sécurisé. Pourquoi stocker des informations dans un fichier zip moins sécurisé? Je pense également que l'affirmation selon laquelle l'utilisation de fichiers zip est évidemment fausse est un peu extrême. Techniquement, la solution zippée (si elle est mise en œuvre soigneusement) n'est que très encombrante et présente une mauvaise mise en œuvre d'une SCM.
Les systèmes de contrôle de la version prennent en charge le contrôle d'accès utilisateur, les fichiers zip ne sont généralement pas. Je suis d'accord sur la fonctionnalité Les systèmes pauvres et encombrants (en particulier si vous ajoutez "peu fiable"), c'est pourquoi j'ai spécifiquement mentionné deux qui ne sont pas.
Un autre bon point. En ce qui concerne le contrôle d'accès des utilisateurs, je voudrais mentionner cela avec les fonctionnalités non prises en charge que vous devriez effectuer d'autres hébergements si vous êtes allé l'approche ZIP. D'où le commentaire "Caractéristiques pauvres".
Sécurisé peut également signifier que, avec zip, vous pouvez physiquement (accidentellement) Supprimer un fichier à partir de celui-ci, avec un système de contrôle source, vous devez passer aux grandes longueurs pour supprimer définitivement quelque chose.
N'oubliez pas blâme :)
C'est "Annotation des fichiers source pour suivre l'origine d'un changement". J'aime que svn a trois alias pour cette commande: Annoter, blâmer, louange!
Ne forgez pas bisiger pour trouver des erreurs et fusion .
Ce n'est pas bon, car il ne s'agit que d'une fermeture à glissière avant qu'une libération signifie perdre beaucoup d'énergie que vous obtenez avec la version de la version.
utilement, vous devez vous enregistrer sur le référentiel après avoir été ajouté / supprimé / modifié un ASPEKT fonctionnel. Afin que vous puissiez revenir plus tard lorsqu'une erreur se produise que vous pensez que la migue est à cause de ce changement. Ou quand vous dites "Dammé, cela a fonctionné avant le format de fichier changé dans un jour en mars." Nommer les révisions après les modifications, il est également plus facile de rappeler que vous avez oublié ce qui a été fait le 27 mars 2009.
Je suppose que cette question a été posée parce que l'affiche originale travaille dans un bureau où la pratique standard consiste à partager des fichiers ZIP.
Les fichiers zip sont évidemment mauvais, pour les raisons données par NED Batchelder. La principale raison pour laquelle je suggérerais est que c'est clunky et difficile à fusionner des changements, ou de faire des diffuses entre les révisions passées facilement.
Je vous recommanderais de lire Un guide visuel sur la version Control < / a> Pour de bons arguments sur la raison pour laquelle les systèmes de contrôle de la version sont très utiles et une manière supérieure de gestion du code.
En général, chaque développeur fonctionne sur leur propre programme et a un responsabilité pour cela. Mais il y a fois bien sûr lorsque d'autres développeurs sont impliqués dans le travail sur ce programme.
Dans un magasin de développement normal, ce n'est pas du tout vrai. Différentes personnes travaillent sur le même code source tout le temps. XP le rend presque obligatoire. Même si vous séparez le code en modules, il y aura toujours des points d'interaction avec le code qui concerne au moins deux programmeurs.
Bien sûr, il est presque impossible de collaborer sans problèmes majeurs si vous n'utilisez pas le contrôle de la source. Mais le scénario que vous décrivez est beaucoup plus un moyen de s'adapter à cette limitation qu'une structure de projet sain.
Avoir une seule personne travaillant sur un module signifie que rien ne se passera quand cette personne est en vacances et que vous avez un problème majeur lorsqu'il quitte l'entreprise, tombe malade depuis longtemps ou meurt.
Je suppose que vous travaillez actuellement dans une entreprise qui pratique cette méthode de contrôle ZIP, et vous recherchez des munitions pour vous aider à changer cette pratique. Il y a beaucoup de questions sur Stackoverflow sur le contrôle de la source, et la communauté ici est un consensus presque total sur les avantages du contrôle de la source approprié et des horreurs de travail sans elle (pour une très bonne raison).
Je vais ajouter quelque chose ici pour profiter à votre bataille: Votre entreprise est @ $ #% & $ # @ Crazy !!! Fichiers Zip ??? Es-tu @ # $ # @% je te moque de moi ???
Je suis impliqué dans un certain nombre de configurations de développement "intéressantes" dans mes nombreuses années dans de nombreux endroits. Rien ne me fait vraiment beaucoup d'excitation. Votre deuxième paragraphe décrit parfaitement ma réaction aux fichiers zip ... :-)
@Brian: quelqu'un devait le dire. :)
Ma réaction aux fichiers zip serait probablement "o.o pourquoi ?!" suivi de la création d'une machine virtuelle Linux sur ma machine de développement et de configurer un serveur SVN.
@Adam: Cela ressemble à la lutte contre le feu avec de l'eau. Qui fait ça? :)
Pourrait être pire - ils pourraient utiliser SourceSafe.
Comment faites-vous une fusion? Comment faites-vous une annotation? Comment vous bisectez-vous? Où sont stocké des changelogs? Il suffit d'aller à Wikipedia et recherchez «Contrôle de la version» et descendez la liste: les fichiers ZIP peuvent en quelque sorte faire une sorte de 2 choses sur la page.
Ceci est comme demander "quels arguments peuvent être utilisés contre le sténographie comme une forme de comptabilité à double entrée?". C'est une chose complètement différente.
Ces arguments sont un peu faibles. Je parie que les efforts de développement dans ce magasin sont suffisamment petits pour que ces problèmes ne prennent pas beaucoup de choses si du tout. Si quelque chose, des concepts plus avancés dans SCM comme la ramification vont faire plus pour les effrayer que les dessiner. Surtout étant donné qu'ils utilisent probablement zip car quelqu'un pense que c'est la solution la plus simple qui fonctionne.
@JOHNFX: Une chose à propos de jouer à l'avocat du diable est que vous êtes toujours sur le côté perdant.
JOHNFX: J'utilise BidSect sur des projets solo sous 1000 LOC. Il est difficile d'imaginer un projet d'entreprise si petit qu'il ne pouvait en tirer parti.
Je soupçonne qu'il y aura autant de papiers blancs comparant des fichiers zip à un contrôle de source approprié, car il y aura des papiers blancs comparant la découpe de ses organes génitaux avec un couteau de beurre rouillé avec un chiot.
La solution zippée nécessite une étape pro-active à la fin du cycle de développement lorsque les choses ont tendance à être abandonnées car personne en dehors du groupe DEV Avis quand ils ne se produisent pas. En quelque sorte comme ce nettoyage de code final, vous prévoyez toujours de faire quand les choses ralentissent.
Un SCM intégré à l'environnement DEV applique à peu près / encourage à maintenir une historique de la version avec une petite quantité d'efforts tout au long du processus. Cela rend davantage probable qu'une histoire de la version sera réellement créée.
Gestionnaires non-technologiques / compteurs de haricots: Il existe des outils gratuits / peu coûteux qui réduiront le coût du travail de la version et donner une plus grande responsabilité / transparence dans ce que chaque développeur fait / la source de codage la plupart des meutes.
Je ne vais pas prendre aussi durement une ligne que certains des autres sur la solution de fichier zip. C'est au moins mieux que rien. Il s'agit d'une manière parfaitement valide de garder les histoires de la version, il s'agit simplement d'une grande plus de main-d'œuvre intensif, d'erreur sujette et de nombreuses fonctionnalités utiles.
Ces personnes connaissent déjà tous les arguments de SCM, il n'y a rien que personne ne peut leur dire qui les vendrai. Ces choses doivent arriver:
Vous installez SCM sur votre machine locale et utilisez-la. Si vous devez, demandez-lui d'autogénérer ces fichiers .zip à chaque construction, alors personne en dehors de votre cube ne connaît la différence.
Une sorte de catastrophe survient, comme la perte de travail, le bug de show-bouchon est réintroduit ou un autre scénario pire des cas de la vraie raison que nous utilisons tous SCM (les autres fonctionnalités que nous apprenons à apprécier plus tard ).
Vous n'êtes pas affecté par la catastrophe et / ou utilisez votre copie personnelle du code dans SCM pour résoudre le problème / récupérer le travail perdu / autre.
Vous êtes un héros et tout le monde veut savoir comment vous l'avez fait.
Seulement en éprouvant de la force de première main, la douleur des pertes causées par les mauvaises pratiques SCM que votre organisation réalisera les avantages du SCM. Vous êtes assez intelligent pour apprendre des erreurs des autres, mais pas tout le monde n'est pas. Le reste de l'époque, vous serez juste de 2/3 fois plus productif que le reste de l'équipe et peut-être, peut-être qu'elles vont se demander comment.
Au fait, voici comment vous obtenez une intégration agile, une intégration continue, des tests unitaires, etc. dans l'organisation: Diriger par exemple.
Pour les arguments, il y a Walter Tichy's papier original sur RCS .
Pour des fonctionnalités manquantes, parmi beaucoup d'autres, il y a la capacité de Fusionner des modifications de différentes versions . Ceci est particulièrement bien soutenu par des outils tels que Git et Darcs, et dans une moindre mesure mercuriaire.
P.s. Ventilateurs mercuriels: le problème est que Mercurial déléguette le processus de fusion aux outils externes, et il est très difficile pour le novice mercurial de savoir quel outil utiliser ou de comprendre comment ils travaillent - le modèle mercurial de la fusion semble bien plus puissant que d'autres. mais en conséquence difficile pour obtenir une prise en main.
Je n'ai pas vu de réponse inclure l'Eric Sinsks's HOWTO de contrôle de source , mais C'est une référence précieuse. Je n'ai vu aucun article blanc formel sur le contrôle de la version, mais je ne suis pas sûr que l'argument sur la "validité" est votre plus fort. Les problèmes que vous décrivez dans votre question indiquent des inconvénients assez graves avec l'approche actuelle. Si "les pouvoirs" dans votre environnement ne sont pas convaincus par cela, changez entièrement l'argument.
Si vous en prenez une question de contrôle de la qualité et indiquez une intégration continue comme une pratique qui l'encourage, l'approche du fichier zip de la version de la version n'est pas une forme de contrôle de la version non valide, mais un obstacle mettre en œuvre une intégration continue comme une pratique.
Votre question n'indique pas si le produit final "sous contrôle" est testé sous une mode automatisée (en plus d'être examiné). Si le processus que vous décrivez empêcherait cela de se dérouler également, ajoutez certainement cela à votre argument.
Vous m'avez battu - cette fois! :-)
Les fichiers zip fonctionnent comme une forme de contrôle de version très basique. C'est un moyen de séparer des "états" de la source. Cependant, ce n'est pas un bon forme de contrôle de la version car vous devez faire beaucoup de travail pour effectuer des tâches de gestion de base de contrôle de la source. Par exemple:
Ce ne sont que trois scénarios qu'un système de contrôle de version gère bien. La situation 1 est traitée par des branches de développement. Presque chaque système de contrôle de version a une notion de branches pouvant être développée en parallèle et fusionnée au besoin. Situation 2 est facilement traitée par tout système de contrôle de source avec une fonctionnalité «blâme» et moins facilement adressée en recherchant simplement des journaux de validation. Situation 3 est une variante de la situation 1, mais lorsque vous fusionnez des succursales, la plupart des systèmes de contrôle de la version font une note. Par exemple, vous feriez une succursale de l'ancienne version, corrige le bogue, puis fusionne cette branche dans le nouveau code. Maintenant, quand quelqu'un demande "Où vient ce changement?" Ils voient qu'il a été fusionné de la branche de correctif et le changement a été fait pour corriger un bogue.
Au fait, j'ai été dans chacune de ces 3 situations et utilisé à la fois SVN et Perforce; les deux ont fait trouver une solution très facile.
J'ai écrit un outil de contrôle de version il y a longtemps pour une entreprise qui a effectué la création de titres de DVD. Avant qu'ils n'avaient rien, juste un répertoire rempli de clips, d'icônes, de scripts, etc. que quiconque pouvait pirater, et aucun moyen de revenir en arrière si elle a mal tourné, etc. Cependant, ces personnes étaient des «artistes», pas des programmeurs, ils pouvaient donc pas (ne serait pas ???!) Soyez formé pour utiliser un système de contrôle de la version décent. Donc, en tant qu'outil de niveau minimum minimum, de niveau de la boue, j'ai écrit un utilitaire qui a consisté l'état actuel de l'annuaire, a donné le nom significatif de la fermeture à zip (date + commentaire fourni par l'utilisateur) et l'a coincée. un répertoire de sauvegarde et vous permet également de restaurer une de ces sauvegardes.
Les zips peuvent donc fournir un contrôle de version au niveau minimum, et je parle comme une personne qui a approuvé cette approche lorsqu'il était juste pour le niveau de compétence (en termes de programmation, je ne veux pas impliquer qu'ils ne pouvaient pas manipuler pixels!) des gens qui l'utilisent.
Mais en tant que programmeur, vous devriez penser à utiliser un outil qui vous aide vraiment. En tant que tel, vous souhaitez être en mesure de comparer les différences pour des fichiers individuels, comparez les différences entre les jeux de jalons complets et (si vous travaillez sur autre chose que des programmes triviaux) gérer la ramification et la fusion. Si vous voulez ces fonctionnalités, vous avez besoin de quelque chose de mieux que des fichiers ZIP.
J'avais l'habitude d'utiliser des Componchsoftware RCS, et si ce n'était pas pour ses mauvaises performances sur un WAN, nous pourrions toujours l'utiliser: il est bon marché (même gratuit pour une utilisation mono-développeur, dans lequel la forme que je l'utilisais. à la maison) et simple à utiliser. Cependant, je suggérerais de regarder Subversion. Il est très flexible, raisonnablement simple à comprendre, a un bon ensemble d'outils Windows pour la rendre encore plus facile (par exemple, tortue, ankh) et ... meilleur de tous ... Vous pouvez le faire courir gratuitement.
Je pense que votre meilleur argument montre une bonne forme de contrôle de la source et montrant à quel point il est puissant. Ne déduisez pas ce qui est actuellement fait (comme une personne est sûrement attachée émotionnellement à cela). Vous ne voulez pas détruire la "méthode de contrôle de la source zippée". Montrer le pouvoir de quelque chose comme svn. Rendre très facile à expliquer. Montrer des cas d'utilisation courants. (Une démo solide aiderait.)
Laissez la version de contrôle source se vendre elle-même.
Avec la version de version, vous verrez une augmentation massive de la productivité. Comme la différence entre la marche et le vol (en étant attaché à un booster de fusée)
@Darknight: On dirait que vous vendez des outils SCM. =) Ce n'est pas nécessairement toujours vrai et je dirais que rarement est-ce une "culture massive de productivité". Parfois, en fait, le travail supplémentaire pour gérer le SCM peut réduire la productivité, mais c'est un bon compromis d'avoir la piste d'audit et d'autres avantages d'un bon référentiel SC.