Est-il inhabituel pour une petite entreprise (15 développeurs) de ne pas utiliser le contrôle de source / version managé?
Ce n'est pas vraiment une question technique, mais il y a plusieurs autres questions ici sur le contrôle des sources et les meilleures pratiques.
La société pour laquelle je travaille (qui restera anonyme) utilise un partage réseau pour héberger son code source et son code publié. Il est de la responsabilité du développeur ou du gestionnaire de déplacer manuellement le code source dans le bon dossier selon qu'il a été publié et de quelle version il s'agit. Nous avons plusieurs feuilles de calcul parsemées où nous enregistrons les noms et les versions des fichiers et ce qui a changé, et certaines équipes mettent également des détails sur les différentes versions en haut de chaque fichier. Chaque équipe (2-3 équipes) semble procéder différemment au sein de l'entreprise. Comme vous pouvez l'imaginer, c'est un gâchis organisé - organisé, parce que les "bonnes personnes" savent où se trouvent leurs affaires, mais un gâchis parce que tout est différent et que cela dépend des gens qui se souviennent de ce qu'il faut faire à tout moment. Une bonne chose est que tout est sauvegardé tous les soirs et conservé indéfiniment, donc si des erreurs sont faites, des instantanés peuvent être récupérés.
J'essaie de pousser pour une sorte de contrôle de source géré depuis un certain temps, mais je n'arrive pas à obtenir suffisamment de support pour cela au sein de l'entreprise. Mes principaux arguments sont:
- Nous sommes actuellement vulnérables; à tout moment, quelqu'un pourrait oublier de faire l'une des nombreuses actions de libération que nous devons faire, ce qui pourrait signifier que des versions entières ne sont pas stockées correctement. Cela peut prendre des heures, voire des jours, pour reconstituer une version si nécessaire
- Nous développons de nouvelles fonctionnalités avec des corrections de bugs, et nous devons souvent retarder la sortie de l'un ou de l'autre car certains travaux ne sont pas encore terminés. Nous devons également obliger les clients à prendre des versions qui incluent de nouvelles fonctionnalités même s'ils veulent juste une correction de bogue, car il n'y a vraiment qu'une seule version sur laquelle nous travaillons tous
- Nous rencontrons des problèmes avec Visual Studio car plusieurs développeurs utilisent les mêmes projets en même temps (pas les mêmes fichiers, mais cela pose toujours des problèmes)
- Il n'y a que 15 développeurs, mais nous faisons tous des choses différemment; ne serait-il pas préférable d'avoir une approche standard à l'échelle de l'entreprise que nous devons tous suivre?
Mes questions sont:
- Est-il normal qu'un groupe de cette taille ne dispose pas du contrôle de source?
- Jusqu'à présent, on ne m'a donné que de vagues raisons pour ne pas avoir de contrôle de source - quelles raisons suggéreriez-vous pourrait être valable pour pas mettre en œuvre le contrôle des sources, compte tenu des informations ci-dessus?
- Y a-t-il d'autres raisons pour le contrôle des sources que je pourrais ajouter à mon arsenal?
Je demande principalement à comprendre pourquoi j'ai eu tant de résistance, alors veuillez répondre honnêtement.
Je vais donner la réponse à la personne qui, selon moi, a adopté l'approche la plus équilibrée et a répondu aux trois questions.
Merci d'avance
- Ce n'est peut-être pas normal, mais comme Treb dit , ce n'est probablement pas que inhabituel
Comme d'autres l'ont dit, il n'y a aucune raison valide de ne pas avoir le contrôle de code source dans une entreprise de votre taille. Vous devez donc identifier et attaquer les raisons invalides:
a) le principal est le statu quo : "si ce n'est pas cassé, ne le répare pas". C'est difficile: vous pouvez commencer à signaler toutes les choses qui ne fonctionnent pas aussi bien qu'elles le devraient (ce qui peut rapidement vous faire étiqueter comme une `` personne négative ''), ou vous attendez simplement que quelque chose explose (ce qui pourrait ne jamais se produire), ou vous pourriez souligner toutes les choses qui pourraient mal tourner. Malheureusement, les responsables de petites entreprises sont relativement insensibles aux "choses qui pourraient mal tourner" jusqu'à ce qu'ils font tournent mal ...
b) ignorance/peur/incertitude : "nous ne comprenons pas vraiment ce qu'est le contrôle de source; nous ne savons pas comment utiliser il; nous ne savons pas quel outil choisir; il va restreindre notre style ". C'est une des raisons pour lesquelles je définitivement ne le ferait pas les envoyer ici ! Cela pourrait être une tâche assez difficile pour vous seul, mais je pense que pour maximiser vos chances, vous devez présenter une solution "clé en main", et pas trop de variantes ou d'alternatives. Vous avez besoin d'une idée claire de: comment vous voulez adapter/transformer votre processus de travail pour travailler avec l'outil donné; comment/si vous prévoyez de porter en arrière le code existant; à quelle vitesse vous pensez pouvoir "former" les utilisateurs et les faire fonctionner; comment gérer la période de transition (s'il y en a une); combien il est susceptible de "coûter" (en heures, sinon en dollars).
c) il peut y avoir d'autres raisons (mauvaises expériences précédentes avec VSS par exemple, ou avoir lu des 'histoires d'horreur' sur des outils prétendument trop compliqués), mais vous devrez les battre individuellement lorsque vous les découvrirez.
Il y a de nombreuses raisons pour le contrôle de source décrit dans les autres réponses. Mon conseil serait de choisir les 2 ou 3 principaux qui pourraient vraiment faire une différence pour votre entreprise et les peaufiner et les présenter lors d'une réunion à autant de vos collègues que possible. Essayez de provoquer la discussion: même si vous ne les convainquez pas immédiatement, vous comprendrez quels peuvent être les points de friction.
(Avez-vous lu/entendu parler de La fonction de changement ?)
Il n'est absolument pas normal qu'un groupe de cette taille fonctionne sans contrôle de source - la taille du plus grand groupe de programmeurs pouvant fonctionner efficacement sans contrôle de source est inférieure ou égale à un. C'est absolument inexcusable de travailler sans contrôle de version pour une équipe professionnelle de n'importe quelle taille, et peut-être que je ne me sens pas créatif, mais je ne peux trouver aucune raison pour laquelle vous voudriez y renoncer.
Le contrôle de version n'est qu'un autre outil, particulièrement puissant et qui offre des avantages énormes par rapport à son coût minimal. Il vous donne le pouvoir de gérer finement tous vos changements de manière organisée, avec toutes sortes d'autres choses pratiques comme la ramification, la fusion automatisée, le balisage, etc. Si vous avez besoin de construire une version à partir d'énormes versions il y a, vous pouvez consulter le code à partir de ce moment et juste construire sans avoir à passer par d'autres cerceaux.
Plus important encore, si vous avez besoin d'écrire un correctif, vous pouvez le fusionner dans une mise à jour sans avoir à fournir les nouvelles fonctionnalités sur lesquelles vous travaillez - car elles sont sur une autre branche, et dans la mesure où le reste du développement doit soyez inquiets, ils n'existent pas encore.
Vous rencontrez de la résistance parce que vous remettez en question la culture de l'entreprise. Il leur faudra du temps pour s'adapter, peu importe ce que vous dites. Le mieux que vous puissiez faire est de continuer à pousser pour cela, et si l'entreprise ne bouge vraiment pas, trouvez un autre emploi qui convient mieux à votre niveau en tant que développeur.
Est-il normal qu'un groupe de cette taille ne dispose pas du contrôle de source?
D'après mon expérience, ce n'est pas la norme, mais pas aussi complètement inhabituel que d'autres réponses suggèrent ici. La majorité des petites entreprises utilisent le contrôle des sources, mais un nombre important ne le fait malheureusement pas.
Jusqu'à présent, on ne m'a donné que de vagues raisons pour ne pas avoir le contrôle de source - quelles raisons suggéreriez-vous pourraient être valables pour ne pas mettre en œuvre le contrôle de source, compte tenu des informations ci-dessus?
Voir cette question sur SO pour une bonne discussion. La réponse acceptée dit:
"Il n'y a pas de bonnes raisons de ne pas utiliser le contrôle de version. Pas une seule."
Y a-t-il d'autres raisons de contrôler les sources que je pourrais ajouter à mon arsenal?
Le consensus entre tous les développeurs et chefs de projet que j'ai rencontrés, et bien sûr ici sur les programmeurs et SO est que le contrôle des sources est un must. C'est un meilleur accepté . Si quelqu'un décide de l'ignorer, il doit avoir des arguments très solides et convaincants pour expliquer pourquoi c'est la bonne décision pour lui (c'est-à-dire un peu plus que "nous n'en avons jamais eu besoin, alors pourquoi si nous en avons besoin à l'avenir "). Les arguments que vous avez présentés jusqu'à présent sont centrés sur des questions spécifiques, peut-être devriez-vous essayer une approche plus large du type" Tout le monde le fait, alors pourquoi pas nous aussi? "
Le contrôle des sources est bon, même pour une seule équipe de développeurs. Tout système de contrôle de source est essentiellement un système de contrôle de version qui garde la trace des changements. Imaginez un seul développeur, qui pourrait avoir supprimé du code et estime que le code est maintenant requis. Peut-il récupérer l'ancien code?
Optez simplement pour un outil qui vous aide. La taille n'a pas d'importance partout. La qualité compte partout.
Il semble que vous utilisiez déjà un système de contrôle de version, mais pas très bon. Les gens semblent déjà reconnaître le besoin de contrôle de version. Vous avez juste besoin de les introduire au niveau suivant - le contrôle de version du logiciel.
Si c'était moi, je présenterais SCM comme une version améliorée de ce qu'ils font déjà. Je voudrais souligner comment l'utilisation d'un bon outil automatisera une grande partie du travail déjà en cours.
Au lieu d'enregistrer les modifications dans une feuille de calcul, le système SCM garde une trace non seulement de ce qui a changé, mais de qui l'a changé et pourquoi.
En prime, vous pouvez revenir à n'importe quel moment de la vie du code et voir ce qui était réellement là.
Au lieu d'avoir différentes versions de code dans différents dossiers et d'avoir besoin de déplacer/fusionner des choses entre les dossiers pour porter une modification, vous pouvez tout garder au même endroit et (plus important encore), laisser l'outil faire la fusion.
Comme d'autres l'ont déjà dit, je m'attendrais à une certaine résistance, alors je prototyperais le système en l'utilisant sur ce que je fais.
(BTW, j'ai en fait mis mon CV et d'autres documents sous SVN. Là encore, j'ai joué plusieurs fois les rôles de gestionnaires de configuration et d'intégration.)
Jusqu'à présent, on ne m'a donné que de vagues raisons pour ne pas avoir de contrôle de source - quelles raisons suggéreriez-vous pourrait être valable pour pas mettre en œuvre le contrôle des sources, compte tenu des informations ci-dessus?
Le produit que vous développez est un système de contrôle de version; les gestionnaires sont soucieux d'empêcher les produits existants d'influencer la conception et la mise en œuvre du nouveau produit.
Entre les week-ends de BASE de saut et de course avec des taureaux, les managers à la recherche de sensations fortes aiment conduire au travail en se demandant si tout est déjà allé en enfer.
Évite les prises de contrôle hostiles. Qui voudrait acquérir une équipe de développement logiciel gérée de cette façon?
Y a-t-il d'autres raisons de contrôler les sources que je pourrais ajouter à mon arsenal?
Vous faites déjà du contrôle de version, mais vous le faites actuellement de la manière la moins efficace, la plus laborieuse et la plus sujette aux erreurs imaginables. L'utilisation d'un VCS permettra d'économiser de l'argent, de gagner du temps et d'améliorer la qualité.
Économise de l'espace disque. La plupart des systèmes de contrôle de version enregistrent uniquement les deltas entre les fichiers. Actuellement, vous enregistrez une copie complète de chaque version de chaque fichier. (La sauvegarde de toutes ces copies doit prendre beaucoup de temps et d'espace!)
Plusieurs développeurs peuvent travailler sur le même fichier en même temps et concilier les différences sans trop de problèmes. La fusion des modifications est bien sûr possible sans VCS, mais il est presque impossible de savoir qui a changé quoi, quand et pourquoi dans ce cas.
Donne aux développeurs la liberté d'essayer de nouvelles idées en sachant qu'ils peuvent récupérer n'importe quelle version à tout moment.
Un meilleur processus facilite l'embauche et la rétention de développeurs talentueux.
Est-il normal qu'un groupe de cette taille n'ait pas de contrôle de source?
Non, absolument pas. Quand j'ai commencé dans mon entreprise actuelle, il y avait une personne à qui vous deviez envoyer votre code modifié, et il le fusionnerait. Je pourrais convaincre tout le monde en jours d'utiliser SVN.
Jusqu'à présent, on ne m'a donné que de vagues raisons pour ne pas avoir le contrôle de source - quelles raisons suggéreriez-vous pourraient être valables pour ne pas implémenter le contrôle de source, compte tenu des informations ci-dessus?
Je pense que la raison pour laquelle vous n'avez entendu que de vagues raisons est qu'il n'y a aucune raison valable de ne pas utiliser le contrôle de version.
Y a-t-il d'autres raisons pour lesquelles je pourrais ajouter à mon arsenal le contrôle des sources?
Oui, il y a beaucoup de raisons.
- La ramification vous donne la possibilité de développer de nouvelles fonctionnalités sans interférer avec d'autres développements.
- Chaque commit vous donne des informations sur ce qui a été changé exactement, qui a fait ce changement et quand ce changement a été fait.
- Vous pouvez facilement valider des corrections de bogues, les déployer sur les clients et laisser de côté les nouvelles fonctionnalités inachevées.
- Vous pouvez conserver différentes versions si les clients ont peur d'aller vers une version plus récente.
- Vous pouvez travailler sur le même projet (même les mêmes fichiers sources!) En toute simplicité.
- Vous pouvez facilement annuler une erreur, en conservant les modifications après cette erreur commise.
Certaines personnes ont du mal à réaliser à quel point le statu quo est mauvais jusqu'à ce qu'elles voient quelque chose de mieux pour elles-mêmes. Ce dont vous avez besoin est un bon démo. Montrez quelques exemples réels de tâches qu'il pourrait améliorer. "Cela m'a pris 4 heures pour retrouver notre système actuel, mais cette seule commande de contrôle de source m'a dit instantanément."
Mon entreprise utilise GIT pour le contrôle de version. L'entreprise est un développeur, un PDG, un agent de sécurité, une femme de ménage et un réceptionniste. Ils sont tous moi. Le contrôle de la version source est un MUST à chaque fois.
Je travaille seul sur de nombreux projets et j'utilise toujours le contrôle de version. La taille n'a pas d'importance. Il est toujours utile d'avoir un contrôle de version.
Il y a une raison pour laquelle il est n ° 1 sur le test Joel: http://www.joelonsoftware.com/articles/fog0000000043.html
En outre, cela rend possible les numéros 2 et 3 de la liste.
Ne pas utiliser le contrôle de code source pose des problèmes, même pour un développeur solo. Le simple fait que vous pouvez éditer impitoyablement sans risquer de perdre quoi que ce soit compense l'effort d'apprentissage en quelques semaines ou jours.
Cela dit, si vous ne pouvez pas convaincre vos gestionnaires d'introduire le contrôle de code source, faites-vous une faveur et utilisez au moins quelque chose comme git ou Mercurial localement - si les choses explosent par manque de contrôle de code source, au moins vous ne serez pas le celui qui l'a fait.
WTF?! C'est peut-être la question la plus ridicule que j'aie jamais vue. Vous devez trouver un nouvel emploi. 15 développeurs?! Vous pensez que c'est une petite équipe? C'est insensé. Le gestionnaire doit être immédiatement licencié. Honnêtement, je vais faire des cauchemars après avoir lu cette question. Veuillez nous indiquer le produit que vous vendez afin que nous sachions tous ne pas l'acheter! Je ne sais pas ce qui est plus effrayant, cette question ou les réponses disant que ce n'est pas inhabituel!
Nous étions dans une position similaire avec une équipe de 6 personnes il y a quelques années. L'un des développeurs a pris la décision d'installer SVN sur un serveur de développement où se trouvait le dossier partagé et vient de commencer à l'utiliser.
Tout le monde a emboîté le pas, et peu de temps avant que nous ayons implémenté CI ( CruiseControl ) et révolutionné notre processus de construction et de publication pour inclure l'automatisation et les contrôles de qualité.
Je ne peux pas imaginer comment 15 développeurs peuvent travailler sans aucun contrôle de source. Cependant, à partir de:
(...) utilise un partage réseau pour héberger son code source (...)
Je suppose que vous avez créé le contrôle de version de votre propre pauvre comme VSS (également basé sur un dossier partagé). C'est risqué et pas efficace.
Expliquez à votre patron à quel point c'est mauvais, investissez dans une formation SVN ou GIT de 2 jours et commencez à utiliser un véritable système de contrôle de version pendant que votre code est toujours en forme raisonnable.
Si je ne m'engage pas plusieurs fois par jour, ou du moins avant de partir pour la maison, j'ai l'impression que ... il manque quelque chose, quelque chose ne va pas.
J'ai travaillé une fois dans une entreprise avec seulement 2 développeurs (moi + un administrateur aux cheveux longs), en 1998. Même alors, nous utilisions svn. C'est tellement pratique.
Plusieurs fois dans ma carrière, j'ai perdu une journée de travail parce que j'ai fait quelque chose comme mv au lieu de cp puis rm -rf. Ça m'a fait pleurer et me promener dans les rues de la ville de désespoir.
J'ai travaillé dans 5 entreprises au cours de mes 13 années passées dans la SE, participé à des conférences et n'ai jamais rencontré une entreprise n'utilisant pas le contrôle de version.
Cependant, mon entreprise de design d'intérieur préférée, 20 employés, utilise un tableau blanc pour la gestion de projet + collaboration. Ils savent que c'est faux, mais ils ne semblent pas trouver le temps de mettre à niveau. D'une manière ou d'une autre, cela fonctionne. Ne me demandez pas comment.
Sois un leader. Être un leader signifie faire ce qui est bien; résolution proactive des problèmes. Le leadership ne fait rien parce qu'il n'y a pas assez de consensus. Et un bon leader apprend à reconnaître les situations où l'on doit établir un consensus et quand le faire. Il s'agit clairement d'une situation de faire. Le manque de contrôle du code explosera dans vos visages tôt ou tard.
Les dirigeants ne sont souvent pas dans des postes de direction officiels. Les gens suivront de bons dirigeants décisifs quel que soit leur titre.
Si vos efforts décisifs sont réduits à néant, surtout si cela vient de la direction, c'est un signe clair pour vous de foutre le camp. C'est un frein à votre développement professionnel; et les développeurs compétents et la gestion incompétente ne se mélangent pas, et un incompétent avec le pouvoir vous défoncera.
OK, les flashbacks me parviennent. Se déconnecter. Bonne chance.
LordScree, je suis dans une situation presque identique à vous, mon équipe immédiate est d'environ 15 développeurs. Je suis incrédule (presque horrifié) que le contrôle de source ne soit pas utilisé. Ma réponse initiale à "nous devrions utiliser le contrôle de code source" était "nous n'avons pas le temps de l'implémenter". Pour moi, comme le port de sous-vêtements, le contrôle des sources n'est pas facultatif. Après quelques mois, j'ai moi aussi l'autorisation d'implémenter TFS, choisi par l'organisation car il s'agit de MS et est livré avec un essai de 90 jours. En bout de ligne, il est très difficile de convaincre une organisation de la nécessité du contrôle des sources alors qu'elle se débrouille sans elle. Je dis aux développeurs que chaque fois que vous vous retrouvez à sauvegarder des fichiers, en particulier avec une date dans le nom de fichier ou le répertoire sauvegardé, est un exemple de moment où vous mettez quelque chose dans le contrôle de code source. Je n'ai pas de réponses brillantes pour vous, mais je pense que c'est rare. Je mène la même bataille et je vous tiendrai au courant des progrès. Et j'espère qu'il y aura d'autres progrès que je pourrais chercher ailleurs car je ne peux pas travailler dans le chaos!
- Obtenez un chronomètre,
- Comptez le temps que vous passez dans la feuille de calcul juste pour synchroniser les versions
- Comptez le temps que vous passez à réparer les versions cassées
- compter le nombre de fois que les gens crient dans le couloir "je modifie main.c !, juste pour m'assurer que personne d'autre ne le soit maintenant!".
- compter le nombre de plaintes que vous recevez des clients parce que leur correction de bogue contenait d'autres changements
- compter le délai de sortie juste parce que vous n'avez pas pu synchroniser les versions
- Faites un PowerPoint avec ces données, comparez avec la façon dont les vcs fonctionneraient.
- Gestion du salon
Ce n'est qu'un accident qui attend de se produire. Vous n'avez pas d'historique de code, et d'un seul coup, l'un de vos développeurs pourrait effacer des mois de travail. En tant que petite entreprise, vous ne pouvez pas vous permettre ce genre de revers.
Vous êtes également très exposé sur ce lecteur partagé. Même avec une bonne sauvegarde, combien de temps pouvez-vous vous permettre de ne pas travailler. 1 heure, 1 jour, 1 semaine. Combien de temps faudrait-il pour mettre en place un nouveau serveur, restaurer à partir d'une sauvegarde, etc. Encore une fois, en tant que petite entreprise, vous n'avez probablement pas de matériel supplémentaire en veille et ne pourrez peut-être pas facilement déposer de l'argent pour accélérer l'expédition, etc.
Pensez également au stockage hors site. Une inondation ou un incendie n'est pas vraiment inhabituel. Que se passerait-il s'il y avait un incendie dans le bâtiment après les heures. Combien de mois de travail seraient perdus. Un référentiel de code managé comme github serait utile pour cela. Même l'utilisation d'un simple serveur SVN sur un service hébergé serait une avancée dans ce domaine.
Lors de mon premier travail sérieux en 1990, j'étais le seul développeur travaillant dans mon département et je ne savais pas utiliser le contrôle de code source.
Peu de temps après, j'ai appris, depuis lors, je n'ai jamais vu un projet qui n'en faisait pas l'une des premières choses qu'ils avaient mis en place.
J'ai presque perdu tout mon travail à ce travail car j'ai supprimé un dossier au mauvais niveau. Heureusement, j'avais apporté une copie à la maison sur une disquette 5 "la semaine précédente et j'ai pu recréer les semaines de travail en quelques jours.
Je suppose donc que je considérerais cela comme acceptable si c'était le premier projet pour tout le monde dans l'équipe et que personne ne savait mieux, mais si même une seule personne pouvait réellement expliquer les avantages et que l'équipe n'écoutait toujours pas, je reclassifierais mon opinion du groupe de "naïf" à "dangereusement incompétent" (La résistance à l'utilisation d'un outil avec des avantages aussi largement démontrés est presque criminelle - c'est comme si votre équipe ne faisait pas confiance aux "compilateurs" et insistait pour tout faire en langage assembleur ).
J'ai beaucoup rencontré cela ... dans de petites sociétés d'ingénierie/électroniques où ils font beaucoup de logiciels/matériel embarqués.
Dans ces endroits, le SCM ne fait pas partie de la culture de l'ingénierie électronique. Ils ont généralement un ingénieur par projet, qui a juste besoin de sauvegarder la dernière version.
Ainsi, le branchement/la fusion et même le partage de code sont considérés comme non pertinents. De plus, ces sociétés sont probablement ISO9000, donc le processus, étrange, est probablement documenté.
Dans tous les cas, je/d'autres développeurs viennent de commencer à utiliser SCM personnellement.
nous avons 3 membres du personnel de développement et utilisons le contrôle des sources. Sur mes projets personnels, j'ai un développeur et j'utilise le contrôle de code source. Ce n'est pas seulement utile pour la gestion d'équipe, c'est utile pour pouvoir entreprendre un travail expérimental sans avoir peur de détruire quelque chose.
Le moyen le plus simple de convaincre la direction? Il y a moins de risques pour l'ensemble du produit et cela augmentera la productivité des développeurs à long terme. Les deux sont également vrais, et les deux font appel aux gestionnaires.
Ce n'est en aucun cas un scénario normal et je pense que vous devriez vous battre pour obtenir cette configuration dans votre entreprise. Il a des avantages considérables et n'a pas de sens de s'en rendre compte lorsque vous approchez du Jugement Dernier et ce n'est pas la situation qui relève de Si ce n'est pas cassé, ne le réparez pas
N'importe quelle raison de ne pas l'appliquer ne pourrait être qu'une excuse pour un mauvais travail ou une erreur qui attend.
Dites-leur à quel point il est agréable de trouver ce que l'application était le 1er janvier de cette année
que diriez-vous hé cette fonctionnalité a été ajoutée en mars je pense que nous devons développer un peu plus à ce sujet.
Wow, ce bogue 154256 a été corrigé dans ce commit.
je peux dériver l'application et envoyer le déploiement sans problème les gars que vous pouvez continuer à travailler.
Cela peut continuer encore et encore ... (n'oubliez pas d'ajouter des commentaires sur les commits plus tard, sinon cela viendrait comme une autre question)
J'utilise le contrôle de version pour mes projets individuels et mes projets de travail, où nous avons plus de 30 à 40 personnes travaillant sur le même code à la fois. Le contrôle de version a ses avantages organisationnels, mais la possibilité de revenir sur les fichiers et de modifier les modifications peut vraiment éliminer les maux de tête de la gestion du code ... et en fin de compte, c'est le meilleur scénario pour un programmeur, afin qu'ils puissent se concentrer uniquement sur le codage.
Les raisons de ne pas utiliser le contrôle de version sont assez limitées. Tout ce à quoi je peux penser, c'est l'aspect technique des choses.
- Il y a trop de courbe d'apprentissage pour convertir le flux de travail de l'ensemble de votre personnel afin d'incorporer un système de gestion des versions pour être rentable.
- Votre chef de projet ne pense pas qu'il serait avantageux d'introduire la surcharge dans le flux de travail de gestion et de maintenance d'un référentiel. (Principalement un problème avec les anciens systèmes de gestion des versions)
Il existe de nombreuses raisons d'utiliser un système de gestion des versions. À tout le moins, arrêtez de déplacer les choses. Travaillez avec des patchs. Les systèmes de gestion des versions peuvent faire exactement ce que vous dites faire.
- Vous pouvez travailler sur la prochaine version en même temps que vous corrigez les bogues et les publier séparément.
- Au lieu de déplacer des fichiers d'un emplacement à un autre pour y travailler, vous pouvez créer une branche et la fusionner dans le maître à la fin.
- Chaque développeur peut avoir sa propre copie du code source pour éviter les problèmes avec le même projet ouvert sur plusieurs machines.
- Des accidents se produisent, si le code est gravement cassé, il vous suffit de revenir au dernier numéro de révision en cours.
- Le contrôle de version fonctionne bien avec les suiveurs de bogues et les systèmes d'intégration continue.
Personnellement, en tant qu'équipe d'une personne, j'utilise le versioning, le suivi des bogues, l'intégration continue, la révision du code, la vérification de la cohérence du code, les tests unitaires, les tests Selenium, l'analyse du code source, et il y a peut-être plus que j'oublie. J'avoue, il y a une légère courbe d'apprentissage. Il y a aussi un compromis entre le temps d'administration supplémentaire nécessaire aux étapes supplémentaires que vous automatisez. D'après mon expérience, l'effort économisé l'emporte sur le temps d'administration supplémentaire.
Wow, wow. Bien que je ne pense pas que ce soit la meilleure façon de gérer le contrôle de code, il n'est pas tout à fait inhabituel de travailler dans une entreprise avec 6 développeurs et aucun contrôle de source n'a été utilisé, ils avaient en quelque sorte leur propre façon interne de gérer les fichiers, un gestionnaire de versions et tout cela superviserait tous les changements. En fait, le mantra était que de nouvelles fonctionnalités pouvaient être ajoutées aux projets tant qu'une sorte de commutateur était intégré à la fonctionnalité.
Par exemple, nous travaillions sur un réseau social de qualité ab écrit en PHP et le client voulait que la fonctionnalité puisse s'abonner à un profil utilisateur. Fondamentalement, la fonctionnalité était enveloppée dans un chèque comme celui-ci si (ENABLE_SUBSCRIBE_FUNCTIONALITY == vrai) {puis exécutez le code}
L'endroit où je travaillais n'a jamais eu plus d'un développeur à la fois travaillant sur un fichier particulier, la plupart du temps tout était modulaire, dans ce cas, il n'y avait pas besoin de contrôle de source. Cependant, je pense que les avantages du contrôle de source l'emportent largement sur les inconvénients de ne pas l'avoir dans la plupart des cas.
Le fait même que votre entreprise recourt à des feuilles de calcul documentant les changements de fichiers et ce qui a été changé quand quelque chose comme Git ou Subversion peut gérer cela pour vous est tout simplement ridicule.
Là où je travaille, nous avons le même problème. J'essaie actuellement de faire glisser le contrôle des sources "sous le radar" pour contourner les mêmes problèmes que vous. J'utilise Fossil pour les projets que je développe personnellement.
J'ai récemment installé un serveur Fossil sur le réseau local de l'entreprise, alors c'est encore plus pratique. J'espère qu'en démontrant l'utilité de certains petits projets, je saperai la résistance et nous éloignerons du statu quo des dossiers réseau.
Les principales raisons que j'ai entendues pour ne pas utiliser Fossil ou d'autres VCS sont:
- Beaucoup de "programmeurs" sont des gamins de script, et ne comprendront pas comment l'utiliser
- Ceux qui pourraient apprendre pensent que c'est une nuisance à utiliser
- Ces personnes sont la vieille garde, à l'aise avec les dossiers réseau, donc tout le monde devrait être
- Personne n'a le temps de le configurer correctement ou d'apprendre à l'utiliser
- Bien que les fonctionnalités puissent être excellentes, aucune n'est nécessaire
Comme vous pouvez le voir, j'essaie de contourner ces problèmes en démontrant qu'il est simple à utiliser, déjà configuré, facile à apprendre et que les fonctionnalités en valent la peine.
Enfin, même si vous ne les obligez pas à utiliser le contrôle de code source, tout est dans une arborescence de réseau. Fossil peut version tout dans l'arborescence entière, et vous pouvez le configurer pour qu'il s'exécute chaque fois qu'un changement de fichier se produit, ou au moins toutes les heures. Je l'ai fait pour certains de nos projets qui "n'avaient pas besoin de contrôle de code source" et cela m'a permis de revenir à une bonne version en cas de problème.
Faites-le bien, et ils ne sauront même pas que vous l'avez fait. Ensuite, vous pouvez être le héros qui restaure la construction cassée, et démontre l'utilité de votre outil.
Il semble que vous en soyez convaincu, mais quelqu'un dans l'organisation ne vous donne pas les moyens de le faire. Comme vous pouvez le lire dans les autres commentaires, vous devriez le faire.
Vous pouvez trouver des informations ici: http://www.internetcontact.be/scm/?page_id=358
Le facteur le plus important est que vos clients sont contraints à la dernière succursale "instable" et si vos contrats avec vos clients vous rendent responsable du déploiement de versions instables, votre entreprise perd de l'argent. Vous devriez vraiment vous concentrer sur la stabilité des versions ici. C'est la principale raison du contrôle de source, et il semble que votre principal échec. Les autres ne seront pas beaucoup améliorés en utilisant le contrôle de code source car vous avez déjà des systèmes alternatifs en place.
Maintenant que des outils DVCS comme Git et Mercurial sont disponibles et incroyablement faciles à configurer et à utiliser, il n'y a vraiment aucune excuse pour même une équipe de 1 (!) De ne pas utiliser le contrôle de code source. Il ne s'agit pas de la taille de l'équipe, mais d'avoir un historique commenté de vos modifications et la possibilité de prendre en charge des flux de travail tels que la résolution de problèmes de production tout en travaillant sur une nouvelle version et le suivi de l'état du code source pour différentes versions.
Si on me proposait un travail dans une équipe qui avait atteint cette taille, et qu'aucun des développeurs n'avait suggéré d'utiliser un VCS, ou si la "gestion" les avait empêchés, je refuserais tout. Ce n'est tout simplement pas une façon de travailler acceptable de nos jours.
Vous devriez vous procurer un contrôle de version GIT immédiatement. Vous pouvez même l'utiliser depuis Google Code Project Hosting. Lorsque les autres vous voient en train de valider des modifications en un seul clic alors qu'ils copient manuellement des choses, ils changent peut-être d'avis à ce sujet.