Contrôle de subversion / source uniquement pour le code de production?

J'ai obtenu mon diplôme d'études collégiales en informatique il y a un an et je travaille maintenant dans une petite entreprise de développement Web (moi et un autre développeur, ainsi que des gestionnaires, un service client et un testeur). Jusqu'à juste avant de commencer, il n'y avait pas de système de contrôle des sources. Nous commençons maintenant lentement à implémenter SVN, mais l'autre développeur (senior) (désormais appelé Joe) insiste sur le fait que le seul code qui devrait être validé dans notre référentiel SVN est celui qui a été testé et approuvé comme prêt pour la production. Cela signifie que, sur des projets plus importants, il peut n'y avoir aucun engagement pendant des semaines à la fois ou plus.

Est-ce une pratique normale? Il me semble que nous perdons beaucoup des avantages du contrôle des sources, notamment:

• Suivi précis de l'avancement du projet
• Suivi des problèmes tels qu'ils apparaissent et sont résolus
• Annuler facilement les erreurs
• Sauvegarde facile du code, donc nous ne perdons pas grand-chose si un poste de travail tombe en panne
• Plus facile à identifier exactement quel code s'exécute dans quels sites de production, en supposant que nous tamponnons les révisions en exécutables comme décrit ici
• Collaboration facile (bien que nous ne fassions aucun travail d'équipe; ce sont tous des projets en solo)
• Etc.

EDIT: Je dois souligner qu'historiquement, il n'y a pas eu de véritable travail d'équipe dans cette entreprise; seulement deux développeurs travaillant sur des projets distincts. De plus, beaucoup de projets sont petits, ils peuvent donc être achevés en quelques semaines. Et l'entreprise est en affaires depuis plus d'une décennie et s'entend bien sans contrôle des sources. Les projets sont généralement achevés dans les délais prévus.

Si les projets sont achevés dans leur délai estimé, est-il sûr de supposer que les clients sont des clients satisfaits? :)

Il semble que la société commence également à entreprendre de nouveaux types de projets et traverse des difficultés de croissance ou des «difficultés de déplacement». Beaucoup de suppositions qui se passent ici ... S'il vous plaît, restez avec moi!

Si vous êtes convaincu que l'organisation et le contrôle du code peuvent vous aider, vous et votre équipe en interne, alors SVN devrait être envisagé, à mon humble avis. Vous obtenez des points bonus si cette voie fonctionne et l'entreprise est en mesure de fabriquer des produits de meilleure qualité, ce qui rend les clients plus heureux!

Soyez prudent s'il semble qu'une lutte avec la direction va créer un environnement de travail tendu. Le fait est que les propriétaires ont créé l'entreprise. Et non seulement cela, ils ont fait une entreprise prospère. Il est peu probable qu'ils atteignent un jackpot car ils sont bons au jeu.

Soyez respectueux et vous finirez peut-être par vous faire entendre.

Espérons que cela aboutira à une équipe plus efficace et plus heureuse. D'après mon expérience, c'est difficile à obtenir avec une gestion frustrée.

Joe a à peu près complètement tort. Maintenant, vous pouvez faire valoir que vous avez une branche "propre" qui représente le code approuvé et prêt pour la production. Mais ne pas utiliser le contrôle de source tant que les choses ne sont pas prêtes est carrément voué à l'échec. Un peu comme essayer de faire un martini sans le gin.

Le "senior" est en fait très peu qualifié. Tout code qui peut être compilé (et passe des tests si vous en avez) doit être validé pour le contrôle de code source. Le contrôle des sources est un atout central pour le partage de code et la création incrémentale de logiciels.

Le bon point est de séparer le code de production (dernière version stable) mais dans de tels cas, les systèmes de contrôle de source contiennent des fonctionnalités telles que des balises / étiquettes et des branches.

Notre équipe est très méfiante si quelqu'un ne commet rien dans les deux à trois jours. Cela signifie qu'il a des problèmes et qu'il a peut-être besoin d'aide. Un autre point de contrôle des sources est qu'il est généralement régulièrement sauvegardé, ce qui n'est pas le cas pour les machines de développement. Si votre disque tombe en panne, vous perdez votre travail pendant plusieurs semaines.

En laissant de côté la question de savoir si Joe a raison ou tort (il a tort d'ailleurs), il me semble qu'un compromis pourrait être trouvé si vous utilisiez un système de contrôle de version distribué comme Git ou Mercurial .

De cette façon, vous-même et l'autre développeur travailleriez sur votre référentiel local, validant vos modifications au contrôle de source tôt et souvent, mais ne pousseriez pas vos modifications vers le référentiel "production" jusqu'à ce qu'elles soient "testées et approuvées comme prêtes pour la production". Vous auriez un historique complet de tout ce sur quoi vous avez travaillé au cours des semaines, et Joe aurait un référentiel vierge qui n'avait que l'historique des changements qui étaient bénis comme prêts pour la production.

Cela n'a aucun sens, pour les raisons que vous avez énumérées. C'est comme utiliser le contrôle de version sans les avantages de l'utilisation du contrôle de version.

Je crois que Joe n'a pas compris que les systèmes de contrôle des sources ne sont pas des sauvegardes glorifiées des versions de production de code source, mais un outil utile pour les programmeurs en mettant des mots sur les plus petites étapes de progression et de maturation du code pour votre futur soi et ses collègues. Peut-être que Joe n'est pas habitué à travailler en équipe avec le code d'autres personnes?

Avez-vous déjà pensé «pourquoi cette ligne de code a-t-elle été ajoutée»? Localisez le commit qui l'a introduit et voyez son commentaire. Si vous ne vous engagez que lors de la mise en production, les commentaires ne seront pas suffisamment précis pour vous être utiles.

Je suggérerais également que vous utilisiez un outil plus puissant que SVN. Vous pouvez voir une bonne introduction sur les possibilités à http://hginit.com/ par Joel Spoelsky.

Il utilise du mercure et il y a plusieurs prétendants de nos jours. Git est considéré comme très puissant, et https://github.com/ possède des outils très, très utiles et fournit des comptes de démarrage gratuits afin que vous puissiez l'essayer pour de vrai.

Joe n'a pas l'air de connaître SVN, essayez de vous renseigner sur les branches, les balises et les troncs ... Les balises correspondent à ce que Joe veut. Une lecture des meilleures pratiques SVN ne ferait pas de mal

Je n'ai jamais utilisé SVN, donc je ne sais pas quelles seraient les procédures. Nous utilisons ClearCase, et la pratique ici consiste pour chaque développeur à avoir sa propre branche de développement, puis une branche d'intégration à laquelle nous fusionnons lorsque nous sommes prêts à commencer les tests, et une ou plusieurs branches de publication pour le code intégré et testé .

Joe est un hacker, pas un développeur. Il ressemble à un très bon pirate, mais il se trompe sur la façon d'utiliser le contrôle de révision. Que faire alors?

Il me semble que votre organisation a un investissement dans SVN, et ce serait une limitation de carrière pour vous de défier Joe et d'invalider l'investissement en dollars dans le serveur SVN. Configurez un dépôt GIT et utilisez l'interface git svn pour travailler comme vous le souhaitez (il s'agit de logiciels gratuits et leur configuration prendra entre une heure et une journée, le tout sur votre poste de travail). Socialisez votre flux de travail avec Joe - il peut préserver son système de croyance "repo SVN non pollué" et maintenir sa crédibilité sur l'éléphant blanc cher dans le coin (et l'ego).

Dans un court laps de temps, je m'attends à ce que Joe regarde comment vous travaillez et commence à faire de même. Dans un an ou deux, le serveur SVN deviendra un repo Git.

Vous pouvez essayer de convaincre Joe avec les arguments ci-dessus. Si cela ne réussit pas, utilisez SVN localement pour votre propre travail de développement et espérons qu'il sera un jour repris par Joe. Si vous ne pouvez pas les convaincre avec des arguments, faites ce que vous êtes convaincu et montrez-leur que cela fonctionne. Type d'approche distribuée mais avec l'outillage existant.

Je vais faire écho à @ Carson63000 ici et dire que j'ai déjà vu cette attitude auparavant, et elle est largement causée par les capacités de branchement / fusion horribles du VCS. Avoir une branche qui compile et réussit les tests, avec des balises pour chaque version, est une excellente approche mais elle ne devrait pas être suivie au point qu'aucun autre code n'est validé. Le DVCS en général, et git en particulier, font de la branche une opération simple et courante et cela réduit beaucoup les difficultés avec ce flux de travail.

La raison pour laquelle les systèmes de contrôle de version prennent en charge les balises est que vous pouvez baliser le code certifié et que votre travail quotidien est toujours engagé. Chaque fois que vous avez un code de qualité de production, vous vous engagez à lui attribuer une balise et vous avez terminé. Vous savez à quel moment précis vous devez revenir en arrière pour obtenir ce que le client a. Et vous pouvez toujours vérifier et comparer différentes versions de votre code. De cette façon, vous pouvez tous deux être satisfaits de ce que vous avez dans la base de données de contrôle des sources. Cela fonctionne pour l'entreprise pour laquelle je travaille, qui compte 100 développeurs, travaillant tous sur le même projet. Cela fonctionnera également pour vous.

Il est assez courant de stocker uniquement des éléments dans des systèmes de contrôle de version prêts à être livrés à la production. C'est ainsi que cela a été fait historiquement pendant des décennies, depuis les temps anciens où le stockage sur disque coûtait des centaines de dollars par mégaoctet et tout stocker était tout simplement trop cher.

Ce n'est plus considéré comme la meilleure façon de faire les choses, mais je peux pleinement comprendre pourquoi les gens le font encore, car de nombreux systèmes de contrôle de version plus anciens sont toujours utilisés, ce qui rend difficile, voire impossible, de faire quoi que ce soit d'autre et conserve toujours la connaissance de ce que votre chaque version est (ou plutôt, il n'y a aucun moyen de savoir ce qu'est une version sans vérifier les balises de chaque fichier si vous avez besoin de revenir en arrière. J'ai vu plus d'un référentiel où la seule façon de récupérer une ancienne était de récupérer dans le référentiel un fichier zip avec le code source et les binaires de cette version).