Est-il inhabituel pour une petite entreprise (15 développeurs) de ne pas utiliser le contrôle de source / version géré? [fermé]

Ce n'est pas vraiment une question technique, mais il y a plusieurs autres questions ici sur le contrôle de source et les meilleures pratiques.

La société pour laquelle je travaille (qui restera anonyme) utilise un partage de réseau pour héberger son code source et son code publié. Il incombe au développeur ou au gestionnaire de déplacer manuellement le code source dans le bon dossier, en fonction de sa version et de sa version. Nous avons divers feuilles de calcul en pointillés où nous enregistrons les noms et les versions des fichiers et ce qui a changé, et certaines équipes insèrent également les détails des différentes versions en haut de chaque fichier. Chaque équipe (2 ou 3 équipes) semble le faire différemment au sein de l'entreprise. Comme vous pouvez l’imaginer, c’est un gâchis organisé - organisé, car les "bonnes personnes" savent où se trouvent leurs affaires, mais un gâchis parce que tout est différent et que les gens doivent se rappeler quoi faire à tout moment.

Cela fait un moment que j'essaie de mettre en place un contrôle des sources géré, mais il semble que je ne parvienne pas à obtenir un soutien suffisant au sein de l'entreprise. Mes arguments principaux sont:

• Nous sommes actuellement vulnérables. à tout moment, quelqu'un pourrait oublier de faire l'une des nombreuses actions de publication 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 devons souvent retarder la publication de l’une ou de l’autre, car certains travaux n’ont pas encore abouti. 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’ya 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 les 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:

1. Est-il normal qu'un groupe de cette taille n'ait pas de contrôle de source?
2. Jusqu'ici, on ne m'a donné que des raisons vagues de ne pas avoir de contrôle de source - quelles raisons diriez-vous pourrait être valable pour ne pas mettre en œuvre le contrôle de source, compte tenu des informations ci-dessus?
3. Existe-t-il d'autres raisons de contrôle de source que je pourrais ajouter à mon arsenal?

Je demande principalement à comprendre pourquoi j’ai eu tant de résistance, alors répondez-moi 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

1. Ce n'est peut-être pas normal , mais comme dit Treb , ce n'est probablement pas si inhabituel

2. Comme d'autres l'ont dit, il n'y a aucune raison valable de ne pas avoir le contrôle de source dans une entreprise de votre taille. Vous devez donc identifier et attaquer les raisons non valides :

   a) le principal est le statu quo : "si ce n'est pas cassé, ne le répare pas". C’est difficile: vous pouvez indiquer toutes les choses qui ne fonctionnent pas comme elles le devraient (ce qui peut rapidement vous qualifier de «personne négative»), ou vous attendez simplement que quelque chose explose (ce qui pourrait ne jamais se produire). arriver), ou vous pourriez souligner toutes les choses qui pourraient mal se passer. Malheureusement, les responsables de petites entreprises sont relativement insensibles aux "choses qui pourraient mal tourner" jusqu'à ce que cela ne se passe réellement ...

   b) ignorance / peur / incertitude : "nous ne comprenons pas vraiment ce qu'est le contrôle de source, nous ne savons pas l'utiliser, nous ne savons pas quel outil choisir, cela va gêner notre style" . C'est une des raisons pour lesquelles je ne les enverrais certainement pas ici! Il s’agit peut-être d’une tâche assez ardue pour vous tout seul, mais je pense que pour maximiser vos chances de réussir, 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 souhaitez adapter / transformer votre processus de travail pour utiliser l'outil en question; comment / si vous prévoyez de transférer du code existant; à quelle vitesse pensez-vous pouvoir «former» les utilisateurs et les faire fonctionner? comment gérer la période de transition (s'il en existe une); combien cela va-t-il 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 après avoir lu des "histoires d'horreur" sur des outils prétendument trop compliqués), mais vous devrez les combattre individuellement lorsque vous les découvrez.

3. Il existe de nombreuses raisons pour le contrôle de source décrites dans les autres réponses. Mon conseil serait de choisir les 2 ou 3 principaux qui pourraient vraiment faire la différence pour votre entreprise, de les peaufiner et de les présenter lors d'une réunion au plus grand nombre de vos collègues. Essayez de provoquer la discussion: même si vous ne les convaincez pas immédiatement, vous aurez une idée de ce que peuvent être les points collants.

(Avez-vous lu / entendu parler de la fonction de changement ?)

Il n’est absolument pas normal pour un groupe de cette taille de fonctionner 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 toute 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 offrant des avantages considérables par rapport à son coût minimal. Il vous donne le pouvoir de gérer finement toutes vos modifications de manière organisée, avec toutes sortes d’autres choses utiles, telles que la création de branches, la fusion automatisée, le balisage, etc. Si vous avez besoin de créer une version à partir de nombreuses versions, vous pouvez extraire le code à partir de ce moment-là et le construire sans avoir à sauter par-dessus d'autres obstacles.

Plus important encore, si vous devez écrire un correctif, vous pouvez le fusionner en une mise à jour sans devoir fournir les nouvelles fonctionnalités sur lesquelles vous travaillez, car elles sont situées dans une autre branche et que le reste du développement doit le faire. soyez concernés, ils n'existent pas encore.

Vous rencontrez de la résistance parce que vous défiez la culture de l'entreprise. Peu importe ce que vous dites, il leur faudra du temps pour s’adapter. Le mieux que vous puissiez faire est de continuer à insister, et si l'entreprise ne veut vraiment pas bouger, trouvez un autre emploi mieux adapté à votre niveau de développeur.

Est-il normal qu'un groupe de cette taille n'ait pas de contrôle de source?

D'après mon expérience, ce n'est pas la norme, mais pas aussi inhabituel que d'autres réponses suggèrent ici. La majorité des petites entreprises utilisent le contrôle de source, mais un nombre important ne le fait pas, malheureusement.

Jusqu'ici, on ne m'a donné que des raisons vagues de ne pas avoir de contrôle de source - quelles raisons diriez-vous pourrait être valable 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 indique:
"Il n'y a aucune bonne raison de ne pas utiliser le contrôle de version. Pas une."

Existe-t-il d'autres raisons de contrôle de source que je pourrais ajouter à mon arsenal?

Le consensus entre tous les développeurs et les chefs de projet que j'ai rencontrés, et bien sûr ici sur les programmeurs et les SO, est que le contrôle de source est une nécessité. C'est une pratique exemplaire acceptée . Si quelqu'un décide de ne pas en tenir compte, il doit disposer d'arguments très puissants et convaincants expliquant pourquoi cette décision est la bonne pour lui (c'est-à-dire un peu plus que «nous n'en avons jamais eu besoin, alors pourquoi en aurions-nous 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 de la source est bon même pour une seule équipe de développeurs. Tout système de contrôle de source est fondamentalement un système de contrôle de version qui garde la trace des modifications. Imaginez un développeur unique, qui aurait peut-être supprimé du code et qui estime que le code est maintenant requis. Peut-il récupérer l'ancien code?

Il suffit d'aller pour un outil qui vous aide. La taille n'a pas d'importance partout. La qualité compte partout.

On dirait que vous utilisez déjà un système de contrôle de version, mais pas très bon. Les gens semblent déjà reconnaître le besoin du contrôle de version. Il vous suffit de leur présenter le 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à. J'insiste sur le fait qu'un bon outil automatisera une grande partie du travail en cours.

• Au lieu d'enregistrer les modifications dans une feuille de calcul, le système SCM enregistre non seulement ce qui a changé, mais également qui l'a modifié et pourquoi.

• En prime, vous pouvez revenir à n'importe quel point de la vie du code et voir ce qu'il y avait réellement.

• Au lieu d'avoir différentes versions de code dans différents dossiers et de devoir déplacer / fusionner des éléments pour porter une modification, vous pouvez tout conserver au même endroit et (plus important encore) laisser l'outil effectuer la fusion.

Comme d'autres l'ont déjà dit, je m'attendrais à une certaine résistance et je ferais un prototype du système en l'utilisant sur ce que je fais.

(En passant, j’ai mis mon CV et d’autres documents sous SVN. Là aussi, j’ai joué plusieurs fois le rôle de responsable de la configuration et de l’intégration.)

Jusqu'ici, on ne m'a donné que des raisons vagues de ne pas avoir de contrôle de source - quelles raisons diriez-vous pourrait être valable pour ne pas mettre en œuvre le contrôle de source, compte tenu des informations ci-dessus?

• Le produit que vous développez est un système de contrôle de version. les responsables 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 jump et la course avec des taureaux, les managers en quête de sensations fortes aiment conduire pour se rendre au travail en se demandant si tout est déjà parti en enfer.

• Évite les prises de contrôle hostiles. Qui voudrait acquérir un équipement de développement logiciel géré de cette manière?

Existe-t-il d'autres raisons de contrôle de source 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 que l'on puisse imaginer. L'utilisation d'un VCS permettra d'économiser de l'argent, 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 peine. 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. Lorsque j'ai commencé chez mon entreprise actuelle, il y avait une personne à qui vous devriez envoyer votre code modifié, et il la fusionnerait. Je pourrais convaincre tout le monde d'ici quelques jours d'utiliser SVN.

Jusqu'ici, on ne m'a donné que des raisons vagues de ne pas avoir de contrôle de source - quelles raisons diriez-vous pourrait être valable pour ne pas mettre en œuvre le contrôle de source, compte tenu des informations ci-dessus?

Je pense que la raison pour laquelle vous n’avez entendu que des raisons vagues est qu’il n’existe aucune raison valable de ne pas utiliser le contrôle de version.

Existe-t-il d'autres raisons de contrôle de source que je pourrais ajouter à mon arsenal?

Oui, il y a beaucoup de raisons.

1. Le branchement vous donne la possibilité de développer de nouvelles fonctionnalités sans interférer avec d'autres développements.
2. Chaque commit vous donne des informations sur ce qui a été exactement changé, qui l'a fait et quand.
3. Vous pouvez facilement valider des correctifs, les déployer chez les clients et laisser de côté la nouvelle fonctionnalité inachevée.
4. Vous pouvez gérer différentes versions si les clients craignent une version plus récente.
5. Vous pouvez facilement travailler sur le même projet (même les mêmes fichiers source!).
6. Vous pouvez facilement annuler une erreur en conservant les modifications après cette erreur commise.

Certaines personnes ont du mal à comprendre à quel point le statu quo est mauvais jusqu'à ce qu'elles voient quelque chose de mieux pour elles-mêmes. Ce qu'il vous faut, c'est une bonne démo . Montrez quelques exemples concrets de tâches que cela pourrait améliorer. "Cela m'a pris 4 heures pour retrouver notre système actuel, mais cette commande à contrôle de source unique me l'a dit instantanément."

Ne pas utiliser le contrôle de source, c'est poser des problèmes, même pour un développeur solo. Le simple fait de pouvoir éditer impitoyablement sans risquer de perdre quoi que ce soit compense l'effort d'apprentissage en quelques semaines ou quelques jours.

Cela dit, si vous ne pouvez pas convaincre vos gestionnaires d'introduire le contrôle de source, rendez-vous service et utilisez au moins quelque chose comme git ou mercurial localement - si les choses se gâtent à cause du manque de contrôle de source, vous ne serez au moins le celui qui l'a fait.

Mon entreprise utilise GIT pour le contrôle de version. La société est composée d'un développeur, d'un PDG, d'un agent de sécurité, d'une femme de ménage et d'un réceptionniste. Ils sont tous moi. Le contrôle de version source est un MUST à chaque fois.

Je travaille seul sur beaucoup de 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 # 1 sur le test Joel: http://www.joelonsoftware.com/articles/fog0000000043.html

En outre, cela rend les numéros 2 et 3 de la liste possibles.

Nous étions dans une position similaire avec une équipe de 6 personnes il y a quelques années. L'un des développeurs a choisi d'installer SVN sur un serveur de développement où se trouvait le dossier partagé et vient juste de commencer à l'utiliser.

Tout le monde a emboîté le pas et nous n’avons pas tardé à mettre en œuvre CI ( CruiseControl ) et à révolutionner notre processus de construction et de publication pour inclure l’automatisation et les contrôles de qualité.

WTF?! C'est peut-être la question la plus ridicule que j'ai jamais vue. Vous devez trouver un nouvel emploi. 15 développeurs?! Vous pensez que c'est une petite équipe? C'est insensé. Manager doit être immédiatement résilié. Honnêtement, je vais faire des cauchemars après avoir lu cette question. Merci de 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 des réponses disant que ce n'est pas inhabituel!

Je ne peux pas imaginer comment 15 développeurs peuvent fonctionner sans aucun contrôle de source. Cependant, 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 homme pauvre comme VSS (également basé sur le dossier partagé). C'est risqué et pas efficace.

Expliquez à votre patron à quel point c'est mauvais, investissez dans une formation SVN ou GIT de deux jours et commencez à utiliser un système de contrôle de version réel tant que votre code est en bon état.

Si je ne commets pas plusieurs fois par jour, ou du moins avant de rentrer chez moi, je me sens… quelque chose qui manque, quelque chose qui ne va pas.

J'ai déjà travaillé dans une entreprise avec seulement 2 développeurs (moi + un administrateur aux cheveux longs), en 1998. Même à cette époque, nous utilisions svn. C'est tellement pratique.

Plusieurs fois dans ma carrière, j'ai perdu un jour de travail parce que j'avais fait quelque chose comme mv au lieu de cp puis rm-rf. M'a fait pleurer et errer dans les rues de la ville dans le désespoir.

Au cours de mes 13 années d’existence dans la SE, j’ai travaillé dans cinq entreprises, assisté à certaines conférences et jamais rencontré une entreprise n’ayant pas recours au contrôle de version.

Cependant, ma société de design d'intérieur préférée, 20 employés, utilise un tableau blanc pour la gestion de projet + la collaboration. Ils savent que c'est faux, mais ils ne semblent pas avoir le temps de se mettre à niveau. D'une certaine manière, cela fonctionne bien. Ne me demande pas comment.

Sois un leader. Être un leader, c'est faire ce qui est juste. résoudre les problèmes de manière proactive. Le leadership ne fait rien parce qu'il n'y a pas assez de consensus. Et un bon leader apprend à reconnaître les situations dans lesquelles il faut parvenir à un consensus et quand il faut le faire. Ceci est clairement une situation de faire. L'absence de contrôle de code va exploser dans vos visages tôt ou tard.

Les dirigeants ne sont souvent pas des postes de direction officiels. Les gens suivront de bons leaders, quels que soient leur titre.

Si vos efforts décisifs sont mal accueillis, en particulier par la direction, alors c'est un signe clair pour vous de sortir de là. C'est un frein à votre développement professionnel; Les développeurs compétents et les gestionnaires incompétents ne font pas bon ménage, et un incompétent avec le pouvoir vous décevra.

OK, les flashbacks me parviennent. Se déconnecter. Bonne chance.

1. Obtenez un chronomètre,
   • Comptez le temps que vous passez dans le tableur juste pour la synchronisation des versions
   • Comptez le temps que vous passez à réparer les versions cassées
   • Comptez le nombre de fois où les gens crient dans le couloir " Je suis en train de monter main.c!, juste pour m'assurer que personne d'autre ne l'a en ce moment!" .
   • compter le nombre de plaintes que vous recevez des clients car leur correctif contient d'autres modifications
   • compter le délai de publication simplement parce que vous n'avez pas pu synchroniser les versions
2. Créez un fichier PowerPoint avec ces données, comparez-le à la manière dont vcs fonctionnerait.
3. Gestion du spectacle

Ceci est juste un accident en attente pour arriver. 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 installer 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 vous ne pourrez peut-être pas lâcher facilement de l'argent pour accélérer l'expédition, etc.

Pensez aussi 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 de travail? Combien de mois de travail seraient perdus. Un référentiel de code géré tel que github serait utile pour cela. Même utiliser un simple serveur SVN sur un service hébergé constituerait une avancée dans ce domaine.

LordScree, je suis dans une situation presque identique à vous, mon équipe immédiate compte environ 15 développeurs. Je suis dans l'incrédulité (presque l'horreur) que le contrôle de source n'est pas utilisé. Ma réponse initiale à "nous devrions utiliser le contrôle de source" était "nous n’avons pas le temps de mettre en oeuvre". Pour moi, tout comme le port de sous-vêtements, le contrôle de la source n’est pas facultatif. Après quelques mois, j’ai moi aussi approuvé l’implémentation de TFS, choisi par l’organisation car il s’agit de MS et vient avec un essai de 90 jours. En bout de ligne, il est très difficile de convaincre une organisation du besoin de contrôle à la source quand elle en a profité. Je dis aux développeurs que chaque fois que vous vous trouvez en train de sauvegarder des fichiers, en particulier avec une date dans le nom du fichier ou du répertoire sauvegardé, constitue un exemple de la mise en place d’un élément dans le contrôle de code source. Je ne ' Je n’ai pas de réponses brillantes à vous donner, mais j’estime 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 des progrès, sinon je pourrais chercher ailleurs parce que je ne peux pas travailler dans le chaos!

nous avons 3 membres du personnel de développement et utilisons le contrôle à la source. Sur mes projets personnels, j'ai un développeur et j'utilise le contrôle de source. Ce n'est pas seulement utile pour la gestion d'équipe, mais aussi pour pouvoir faire du travail expérimental sans craindre de détruire quelque chose.

Meilleure façon de convaincre la direction? Le produit global présente moins de risques et accroîtra 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 présente des avantages considérables et ne sert à rien de se rendre compte de la même chose lorsque vous approchez de Doomsday et ce n'est pas la situation qui tombe sous le problème.

N'importe quelle raison pour ne pas le mettre en œuvre ne pourrait être qu'une excuse pour un mauvais travail ou une gaffe en attente.

Il suffit de leur dire à quel point il est génial de trouver ce que l'application a été le 1er janvier de cette année.

que diriez-vous que cette fonctionnalité a été ajoutée en mars, je pense que nous devons développer un peu plus à ce sujet.

Wow ce bug 154256 a été corrigé dans ce commit.

Je peux développer l'application et envoyer le déploiement sans problème, 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, dans lesquels nous avons plus de 30 à 40 personnes travaillant simultanément sur le même code. Le contrôle de version présente des avantages organisationnels, mais la possibilité de restaurer des fichiers et de cacher des modifications peut réellement simplifier la gestion du code ... et qu’il s’agit en définitive du meilleur scénario pour un programmeur, qui peut donc 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.

• La courbe d'apprentissage est trop longue pour convertir le flux de travail de l'ensemble de votre personnel afin qu'il intègre un système de gestion des versions pour qu'il soit rentable.
• Votre chef de projet ne pense pas qu'il serait avantageux d'introduire des frais généraux dans le flux de travail de la gestion et de la maintenance d'un référentiel. (Principalement un problème avec les anciens systèmes de gestion de versions)

Il existe de nombreuses raisons d'utiliser un système de gestion de versions. À tout le moins, arrêtez de déplacer les choses. Travailler avec des correctifs. Les systèmes de gestion de versions peuvent faire exactement ce que vous dites que vous faites.

• Vous pouvez travailler sur la prochaine version en même temps que vous corrigez un bogue et les publions séparément.
• Au lieu de déplacer des fichiers d'un emplacement à un autre pour travailler dessus, vous pouvez créer une branche et la fusionner dans le maître une fois l'opération terminée.
• Chaque développeur peut disposer de sa propre copie du code source pour empêcher les problèmes liés au même projet de s'ouvrir sur plusieurs ordinateurs.
• Il y a des accidents. Si le code est gravement endommagé, il vous suffit de revenir au dernier numéro de révision utilisé.
• Le contrôle de version fonctionne bien avec des systèmes de suivi des bogues et des systèmes d'intégration continue.

Personnellement, en tant qu’équipe unique, j’utilise le contrôle de version, 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 de sélénium, l’analyse du code source, et j’en oublie peut-être davantage. J'admets qu'il y a une légère courbe d'apprentissage. Il existe également un compromis entre le temps d’administration supplémentaire et les étapes supplémentaires que vous automatisez. D'après mon expérience, les efforts épargnés l'emportent sur le temps d'administration supplémentaire.

Lors de mon premier emploi sérieux en 1990, j'étais le seul développeur travaillant dans mon département et ne savais pas utiliser le contrôle de source.

J'ai appris peu de temps après, et depuis lors, je n'ai jamais vu un projet qui n'en faisait pas l'une des premières choses à mettre en place.

J'ai presque perdu tout mon travail à cet emploi parce que j'ai supprimé un dossier au mauvais niveau. Heureusement, j'avais apporté une copie à la maison sur une disquette de 5 pouces la semaine précédente et j'étais capable de recréer les semaines de travail en quelques longs jours.

Je pense donc que je considérerais cela comme acceptable si c’était le premier projet pour tous les membres de l’équipe et que personne ne le savait mieux, mais si même une personne pouvait réellement expliquer les avantages et si l’équipe n’écoutait toujours pas, je reclassifierais mes opinion du groupe de "naïve" à "dangereusement incompétente" (Résister à l'utilisation d'un outil offrant des avantages aussi largement démontrés est presque criminel - c'est comme si votre équipe ne faisait pas confiance aux "Compilateurs" et insistait pour tout faire en langage d'assemblage ).

Je l'ai souvent rencontré ... dans de petites entreprises d'ingénierie / électronique où elles utilisent beaucoup de logiciels / matériel intégrés.

Dans ces endroits, la gestion de la chaîne d'approvisionnement ne fait pas partie de la culture de l'ingénierie électronique. Ils ont généralement un ingénieur par projet, qui n'a besoin que de sauvegarder la dernière version.

Donc, ramifier / fusionner et même partager le code est considéré comme non pertinent. En outre, ces sociétés sont probablement ISO9000, de sorte que le processus, albiet bizarre, est probablement documenté.

Dans tous les cas, je / d'autres développeurs viennent juste de commencer à utiliser SCM personnellement.

Là où je travaille, nous avons le même problème. J'essaie actuellement de faire glisser le contrôle de source "sous le radar" pour résoudre les mêmes problèmes que vous. J'utilise fossile pour les projets que je développe personnellement.

J'ai récemment installé un serveur de fossiles sur le réseau local de l'entreprise. C'est donc encore plus pratique. J'espère que, tout en démontrant l'utilité de certains projets plus modestes, je vais affaiblir la résistance et nous éloigner du statu quo des dossiers réseau.

Les principales raisons que j'ai entendues pour ne pas utiliser de fossile ou un autre VCS sont les suivantes:

1. Beaucoup de "programmeurs" sont des script kiddies et ne comprendront pas comment l'utiliser
2. Ceux qui pourraient apprendre pensent que c'est une nuisance d'utiliser
3. Ces personnes sont la vieille garde, à l'aise avec les dossiers du réseau, donc tout le monde devrait être
4. Personne n'a le temps de bien le configurer ou d'apprendre à l'utiliser
5. Bien que les fonctionnalités puissent être géniales, aucune d’entre elles n’est nécessaire

Comme vous pouvez le constater, j'essaie de les contourner en démontrant que c'est simple à utiliser, déjà configuré, facile à apprendre et que les fonctionnalités en valent vraiment la peine.

Enfin, même si vous ne les obligez pas à utiliser le contrôle de source, tout se trouve dans une arborescence de réseau. Fossil peut mettre à jour tout ce qui se trouve dans l’arborescence et vous pouvez le configurer pour qu’il soit exécuté chaque fois qu’un fichier est modifié, ou au moins toutes les heures. Je l'ai fait pour certains de nos projets qui "n'avaient pas besoin de contrôle de source" et qui m'ont 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. Vous pouvez ensuite être le héros qui restaure la construction brisée et démontre à quel point votre outil est utile.

Maintenant que les outils DVCS tels que Git et Mercurial sont disponibles et incroyablement faciles à configurer et à utiliser, il n’ya aucune excuse pour même une équipe de 1 (!) De ne pas utiliser le contrôle de source. Il ne s'agit pas de la taille de l'équipe, mais de l'historique commenté de vos modifications et de la possibilité de prendre en charge des flux de travail tels que la résolution de problèmes de production lors de la préparation d'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 ne m'avait suggéré d'utiliser un VCS, ou si la direction l'avait empêché, je le refuserais carrément. Ce n'est tout simplement pas une façon acceptable de travailler ces jours-ci.

Vous devriez vous procurer un contrôle de version GIT immédiatement. Vous pouvez l'utiliser même à partir de Google Code Project Hosting. Lorsque les autres voient vos modifications en un clic tout en copiant manuellement des éléments, ils peuvent peut-être changer d'avis.

Wow, juste 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 que je travaille dans une société avec 6 développeurs et qu’aucun contrôle de source n’ait été utilisé; ils avaient en quelque sorte leur propre façon interne de gérer les fichiers, un quoi de neuf superviserait tous les changements. En fait, le mantra était que de nouvelles fonctionnalités pourraient être ajoutées aux projets à condition qu'un certain type de commutateur soit intégré à la fonctionnalité.

Par exemple, nous travaillions sur un réseau social ab grade écrit en PHP et la fonctionnalité souhaitée par le client pour pouvoir s’abonner à un profil d’utilisateur. En gros, la fonctionnalité a été encapsulée dans une vérification comme celle-ci si (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {alors exécutez le code}

L’endroit où j’ai travaillé n’a jamais eu plus d’un développeur à la fois travaillant sur un fichier particulier, la plupart du temps tout était modulaire, de sorte que le contrôle de source n’était pas nécessaire. Cependant, je pense que les avantages du contrôle à la source dépassent de loin les inconvénients de ne pas en disposer dans la plupart des cas.

Le simple fait que votre entreprise ait recours à des feuilles de calcul documentant les modifications de fichiers et ce qui a été modifié lorsque Git ou Subversion peuvent gérer cela à votre place est tout simplement ridicule.

Il semble que vous en soyez convaincu, mais quelqu'un dans l'organisation ne vous autorise pas à 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 forcés de se tourner vers la dernière succursale «instable». 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é de la libération ici. C’est la raison principale du contrôle de la source, et il semble que ce soit votre principal échec. Les autres ne seront pas beaucoup améliorés en utilisant le contrôle de source car vous avez déjà des systèmes alternatifs en place.