Y a-t-il des entreprises sérieuses qui n'utilisent pas le contrôle de version et l'intégration continue? Pourquoi?


17

Un de mes collègues avait l'impression que notre service logiciel était très avancé, car nous utilisions à la fois un serveur de build avec intégration continue et un logiciel de contrôle de version. Cela ne correspondait pas à mon point de vue, car je ne connaissais qu'une seule entreprise que je fabriquais et qui n'en avait pas non plus. Cependant, mon expérience est limitée à une poignée d'entreprises seulement.

Est-ce que quelqu'un connaît une véritable entreprise (plus de 3 programmeurs) , qui est dans le domaine des logiciels et n'utilise pas ces outils? Si une telle entreprise existe, y a-t-il une bonne raison pour qu'elle ne le fasse pas?


3
Ces acteurs logiciels embêtants.
Courses de légèreté avec Monica le

1
les acteurs du logiciel sont-ils différents des développeurs de logiciels?
Aditya P

"Je ne suis pas un logiciel mais j'en joue un à la télé !!" - Acteurs logiciels.
FrustratedWithFormsDesigner

1
Il y a Jayne Seymour, c'est une actrice logicielle sérieuse .... ou du moins elle a joué Solitare dans Live and Let Die :)
Kevin D

3
Là où je travaillais il y a dix ans, nous travaillions tous les soirs sur tous les systèmes pris en charge. Ils n'ont jamais réussi à compiler. Déjà.
David Thornley

Réponses:


5

Je ne suis pas sûr que vous les qualifieriez d'acte sérieux, mais MySpace est assez pauvre sur ce front: voir http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .


1
+1 Ils sont au moins dans la ligue majeure. Je ne pensais pas que c'était possible. Une si grande entreprise sans contrôle de version. Allez comprendre.
daramarak

Fou. Je ne l'aurais pas cru, mais ce blog et les références de l'article sont tous fiables.
Steve

C'est la faute du chien.
JeffO

2
Un site Web pour les adolescents qui commencent un groupe dans un garage est écrit à la manière d'un codeur travaillant depuis leur garage. Les figures.
quant_dev

13

Vous seriez surpris de voir ce que la réalité peut faire au bon sens ;-)

Je pense qu'il y a encore pas mal d'entreprises qui n'utilisent pas de système de contrôle de version. Fait intéressant dans tous les cas que j'ai vus jusqu'à présent, ce n'est pas parce qu'ils s'opposent volontiers à l'utilisation de tels systèmes, mais plutôt parce qu'ils ne savent pas que quelque chose comme SVN existe! Quant à moi: je suis totalement d'accord avec vous et je ne peux pas imaginer une situation où je ne veux utiliser aucun type de contrôle de version. Enfer, je pousse même mes propres fichiers personnels (documents Word, etc.) sur mon PC personnel dans un référentiel GIT.

Dans le cas d'un système d'intégration continue, il est un peu plus courant de ne pas les utiliser dans les opérations quotidiennes. Parfois aussi parce que les gens ne savent pas qu'un tel système existe mais j'ai aussi vu des cas où l'excuse - très discutable - de ne pas les utiliser est que "nous ne sommes pas assez complexes" ou "ça marche très bien sans intégration continue, alors pourquoi s'embêter à ajouter une autre technologie? " Bien sûr, cela ne résiste pas à une évaluation réaliste - mais pour répondre à la question initiale: ce n'est pas si rare.


11
Est-il possible qu'un développeur de logiciel moyen n'ait pas entendu parler du logiciel de contrôle de version? D'où ces entreprises recrutent-elles? Le côté obscur de la Lune?
daramarak

7
@daramarak: Beaucoup (sinon la plupart) de développeurs de logiciels ne lisent pas de livres, ne parcourent pas les blogs de développement et ne communiquent pas du tout avec les autres développeurs (en dehors de leur entreprise). Si vous vous lancez dans le développement en vous enseignant vous-même avec l'un de ces livres «apprenez le visuel de base en 21 jours», il est peu probable que vous entendiez parler de contrôle de version. En fait, je ne me souviens pas d'avoir appris le contrôle de version à l'université, il y a seulement 10 ans.
Joeri Sebrechts

@joeri - heureusement pas vrai où je travaille, mais je peux le croire en général.
Steve

@perdian - vous dites "pas mal d'entreprises" mais ne donnez pas de détails ... avez-vous des liens vers des articles, des blogs, etc. Je ne dis pas que je ne te crois pas (en fait je te crois), mais les données sont toujours bonnes ...
Steve

@Steve Haigh - Non, je n'ai aucune preuve "tangible". J'ai moi-même vu quelques entreprises qui n'utilisent pas le contrôle de version de CI ou plus (dont je garderai les noms pour moi g ) et avec un peu d'extrapolation, je suppose qu'il y en a beaucoup plus "là-bas". Je pense qu'il est beaucoup easiert pour trouver des entreprises qui font usage CI, simplement en regardant la liste de référence sur la page Jenkins par exemple. Mais l'inverse? Il n'y a pas beaucoup de gens qui annoncent "Hé, nous n'utilisons pas la technologie X" ;-)
perdian

12

Presque toutes les entreprises de mon secteur (banque) utilisent actuellement le contrôle de version. Mais il est certainement possible de développer un logiciel avec succès sans contrôle de version. Il y a 20-30 ans. c'est exactement ce que nous avons fait.

Je dirais que de nombreuses banques, peut-être même la majorité, n'utilisent pas de serveur de build à intégration continue. Si vous livrez déjà des logiciels avec succès sans intégration continue, il est parfaitement rationnel de continuer dans cette voie.


3
Je ne suis pas d'accord pour dire qu'il est parfaitement rationnel de "continuer sur cette voie". Oui, avoir livré un logiciel au cours des X dernières années ne signifie pas qu'il ne fonctionnera pas pendant les Y prochaines années sans aucun changement. Cependant, après avoir introduit CI dans les logiciels existants (et assez matures), il y a toujours quelque chose à gagner à cela.
perdian

1
@perdian: il y a toujours quelque chose à gagner de nombreuses initiatives. Vous devez donc équilibrer CI contre tout le reste. Vous ne pouvez pas simplement prétendre que CI vous offre plus d'avantages que tout le reste. Vous devez également mesurer les coûts d'opportunité.
RoadWarrior

1
@ SK-logic: RCS était totalement inconnu à l'époque dans le secteur bancaire britannique. Et nous avons développé des systèmes très grands et robustes sans aucun contrôle de source.
RoadWarrior

1
-1: "Presque toutes les entreprises", c'est une déclaration trop large qui est fausse. J'ai vu au cours de la dernière année des entreprises qui n'utilisent aucun outil de contrôle de version, s'appuyant sur des copies de version sur un répertoire partagé. Oui, cela m'a fait pleurer. Ils ont dit que "svn est trop difficile à utiliser". OMG. Mais je trouve encore des entreprises qui sont comme ça. Ne généralisez pas, tout le monde dans l'industrie ne sait pas ce qu'est un système de contrôle de source, ni n'apprend rien en ligne, ni ne sait ce qu'est une intégration continue. (Je suis d'accord que c'est l'enfer. Heureux de ne plus être là).
Klaim

1
@ SK-logic - ... ce que RoadWarrior a déclaré, sauf dans l'industrie marine / électrique ici. Je ne donnerai pas de noms, mais je connais au moins deux entreprises dominantes dans leur secteur (certains développements de logiciels spécialisés) pour lesquelles je crois n'avoir jamais utilisé de VCS d'aucune sorte (dans votre sens). Ils avaient leurs façons de distinguer le bon code du code de travail en cours.
Rook

7

Juste pour mettre un contre-point à la réponse de @ RoadWarrior:

Je travaille pour une banque. J'ai passé les 3 dernières années à implémenter le contrôle de version et j'ai maintenant réussi à l'obtenir sur environ 20% de notre base de code (ce qui est assez important, nous avons environ 20 développeurs et avons développé nos systèmes pendant> 16 ans)

Grâce à mes contacts dans l'industrie (banque), je connais une tonne d'autres instituts financiers qui n'ont pas ce qu'une personne sensée appellerait le contrôle de version.

Oui, notre industrie (développement de logiciels) est beaucoup plus triste que la plupart voudraient l'admettre.


Mes condoléances. On dirait qu'au moins certaines parties de l'industrie manquent sérieusement d'outils. Je suppose que c'est à nouveau l'histoire des enfants cordonniers. Puis-je demander ce qu'une personne folle appellerait le contrôle de version?
daramarak

6
Prendre manuellement une copie du code avant de le modifier. Par exemple, MyProg -> MyProd.old4
Dan McGrath

Malheureusement, cette pratique est plus courante qu'on ne le pense
Craig T

3

contrôle de version: Dans mon premier travail il y a 25 ans, il n'y avait pas de système de contrôle de version en tant que tel, mais c'était RSX11 sur PDP-11. Cependant, niveau très élevé de contrôle de la qualité avec des examens formels de la conception et du code (c'était dans l'industrie nucléaire).

Depuis lors, chaque travail a utilisé des systèmes de contrôle de version, y compris SCCS, PVCS, clearcase, cvs et perforce.

Donc, d'après mon expérience, l'utilisation du contrôle de version est à peu près universelle dans le développement de logiciels sérieux.

intégration continue: c'est plus un problème, en particulier dans les endroits qui ont beaucoup de code hérité qui n'a probablement même pas beaucoup de tests automatisés. Il faut un très gros investissement pour déplacer le code existant dans un environnement CI, et bien que cela soit finalement payant à la fin, il est difficile d'amener la direction à s'engager dans un tel investissement sans gain à court terme.

J'ai travaillé dans un seul endroit (une grande banque) qui avait CI en place pour certains projets, et nous avons mis en place un type de système CI sur notre projet qui a rendu les choses beaucoup plus faciles, mais a pris environ 6 mois à faire.


Pour les endroits avec du code hérité, ont-ils fait des builds automatisés, ou avaient-ils un plan de construction / déploiement manuel?
daramarak

3

J'imagine que la plupart des entreprises n'utilisent pas ces choses, car elles ne comprennent pas les avantages et leurs développeurs ne veulent pas apprendre ou ont peur de "remuer le pot" en faisant des choses différentes de la façon dont elles ont été fait avant.


3
Absolument! J'ai entendu la réponse (ou peut-être devrions-nous appeler cela une excuse boiteuse) "nous ne l'avons pas utilisé jusqu'à présent et puisque cela a fonctionné (d'une manière ou d'une autre), nous n'en avons pas besoin". Il est dommage que les personnes résilientes ne changent pas leurs outils.
perdian

1
Je ne supporte pas les gens comme ça; malheureusement, c'est le type de "développeur" que j'ai rencontré trop souvent dans ma carrière, et je ne peux tout simplement pas faire face à leur ignorance et je cherche toujours à quitter une entreprise où ces types de développeurs sont répandus. Au risque de paraître carrément hostile, ce genre de personnes est un cancer pour cette profession.
Wayne Molina

2

Bien que je sois maintenant un employé, je travaillais à mon compte comme consultant en base de données. Pendant ces nombreuses années, j'étais dans quelque 800 à 1000 entreprises, du niveau maman-pop aux Fortune 100.

J'ai vu relativement peu d'endroits qui faisaient une intégration continue, mais je ne me souviens pas avoir vu une entreprise qui n'utilisait pas le contrôle de version. J'en ai vu quelques-uns où il n'y avait pas de référentiel centralisé pour le code contrôlé par version. Les programmeurs individuels ont utilisé le contrôle de version soit sur leur propre ordinateur, soit conservé du code contrôlé par version quelque part sous leur répertoire personnel sur le serveur.

Je ne pense pas que l'une de ces sociétés était dans le domaine des logiciels, mais leurs programmeurs l'étaient certainement.


1

Un de mes collègues avait l'impression que notre service logiciel était très avancé car nous utilisions à la fois un serveur de build avec intégration continue et un logiciel de contrôle de version.

Non, je déteste le dire, mais c'est vrai. Les deux derniers endroits où j'ai travaillé (une division d'une banque et une société financière), c'est moi qui ai implémenté le système de contrôle de version. Un certain nombre d'endroits (en particulier les magasins non logiciels) ne comprennent pas pourquoi c'est vraiment nécessaire pour un développement à long terme. L'équipe commence normalement par une ou deux personnes, puis se développe à partir de là, quoique douloureusement. Avec une ou deux personnes, vous pouvez vous en tirer (pas bien) sans lui car vous pouvez être en communication quasi constante les uns avec les autres.

La construction continue est un cas entièrement différent. Si je devais deviner, je parierais que près de 90% des endroits où le développement est effectué n'ont pas de solution CI en place. Je vais à des conférences et la plupart des gens sont stupéfaits qu'une organisation autre qu'un MS ou Google l'ait. Ce que j'ai trouvé, c'est que la direction ne veut pas dépenser la petite somme d'argent pour le faire fonctionner même si cela peut faire gagner beaucoup de temps.

Les principales raisons pour lesquelles j'ai trouvé cela sont:

  1. Les membres de la direction ont gravi les échelons au sein de la même organisation. Ils n'en ont jamais utilisé et n'en ont pas eu besoin, pourquoi devraient-ils changer maintenant? Certains que j'ai trouvés ont juste peur du changement. Quelque chose de nouveau est effrayant, et cela les empêcherait de dépoussiérer leur ancien compilateur et aiderait nos plus jeunes en cas de besoin. D'autres fois (et plus souvent), ils ont des budgets toujours serrés et ils doivent décider où dépenser de l'argent. Pour nous, leur mise en œuvre est un besoin évident, mais c'est parce que nous les avons déjà utilisés. Nous connaissons les avantages, ils ne le savent pas.

  2. Les gestionnaires ne sont pas des informaticiens, et tout ce qu'ils ici, c'est que vous voulez dépenser de l'argent pour quelque chose qui n'était pas nécessaire auparavant.

La plupart des arguments que j'ai entendus de la part des gens se concentrent sur les meilleures pratiques, etc. Avec cette somme d'argent que vous allez dépenser, nous allons économiser X fois et vous avez besoin de chiffres pour la sauvegarder. Ce n'est pas toujours vrai, mais c'est mon expérience dans le passé.


Je peux imaginer que des problèmes comme celui-ci surviennent lorsqu'il y a une mauvaise communication du développeur et vers le haut dans les directions. Heureusement, toutes les entreprises ne sont pas comme ça. Là où je travaille, nous sommes tenus (sinon obligés) de dire à la direction si quelque chose pourrait nous rendre plus efficaces.
daramarak

1

Je dirais que beaucoup de gens n'utilisent pas le contrôle de code source car ils peuvent coder par eux-mêmes et sont habitués à sauvegarder périodiquement la base de code sur un serveur central ou un disque dur USB. Je me suis forcé il y a environ un an à commencer à utiliser SVN parce que je savais que ce serait bénéfique à long terme. Il a fallu un certain temps pour s'y habituer, mais maintenant j'ai des tonnes d'historique de code que je peux constamment consulter. Je souhaite maintenant que je l'avais mis en œuvre il y a quatre ans lorsque j'ai commencé.

Intégration continue? Utilisez-le uniquement si vous en avez besoin. Pour moi, il n'y a que deux ingénieurs logiciels donc nous ne bénéficierions pas d'une intégration continue car nous travaillons nous-mêmes sur nos propres logiciels.


1
L'intégration continue est censée identifier les erreurs lorsqu'elles se produisent. Même deux développeurs en ont besoin.
daramarak

1
@daramarak: Pas si les deux ingénieurs travaillent indépendamment sur deux produits distincts qui ne sont pas intégrés.
Brian

1
CI est l'une de ces choses dont je suis prêt à me passer. Personnellement, j'aimerais l'avoir à mon travail, mais cela ne se produira pas de sitôt. Nous avons cependant des versions automatiques 1 à 2 fois par jour, et c'est vraiment suffisant pour nos besoins.
Michael K

1
Avec une construction automatisée, vous êtes à mi-chemin. Le simple fait de savoir que tout ce qui est compilé dans les compilations peut parfois être une joie ("Il compile sur ma machine")
daramarak

1

Ha, vous pensez que vous êtes avancé parce que vous avez SCM et un système CI? Permettez-moi de vous dire que c'est l'heure des amateurs quand il s'agit.

Beaucoup d'entreprises font le minimum requis, car c'est tout ce dont elles ont vraiment besoin . Si cela fonctionne et que vous obtenez de bonnes versions reproductibles sans effort majeur, il n'y a rien à corriger. La dernière chose que vous voulez faire dans de telles circonstances est de commencer à `` réparer '' les choses, surtout quand il s'agit de retirer les ressources d'administration de leur travail pour configurer et administrer vos nouveaux serveurs et construire des systèmes.

Cependant, certaines entreprises ont besoin de systèmes un peu plus rigoureux en place, une fois que non seulement la construction, mais contrôle les exigences tout au long du déploiement via des plans de test et des résultats de test, prenant en compte la révision du code, les procédures de consignation de style workflow et gestion du lot de travail désigné par le chef d'équipe. C'est une véritable gestion de configuration, et sacrément heureux de ne pas avoir à travailler dans ce genre d'environnement!

J'ai travaillé dans quelques entreprises, et je ne peux penser à aucune qui ne possédait aucune forme de SCM. Certains d'entre eux étaient plus complets que d'autres, mais tous avaient un système qui fonctionnait bien pour eux, même ceux qui utilisaient VSS.


lol! signé: un professionnel.
deadalnix

Je suis d'accord, SCM et un traqueur de bogues sont l'équivalent de développement de porter un pantalon au travail. CI est l'automatisation de base d'une fonction critique. Comme les sauvegardes automatiques mais pour les versions. Ah, les réunions du CCB. Chaque semaine, comme sur des roulettes.
Tim Williscroft

1

Même avec deux programmeurs lorsque vous travaillez sur des applications complexes et une liste de tâches, il peut être difficile de ne pas se marteler mutuellement les changements.

Même notre ancien logiciel de gestion des versions montrait les changements côte à côte et permettait de les appliquer dans les deux sens. Sans elle, des changements auraient été manqués à plusieurs reprises.

Je vois un certain nombre d'avantages qui viennent de CI, mais je ne peux pas imaginer pourquoi une entreprise ne ferait pas usage d'un logiciel de contrôle de version.


1

Le dernier emploi où j'ai travaillé sans contrôle de version remonte à 2006 (je suis développeur Web, FWIW). L'entreprise n'avait que 2 ou 3 développeurs avant de m'engager, mais j'étais le premier d'une dizaine de développeurs embauchés en seulement quelques mois. L'une des premières choses que j'ai faites lors de l'embauche a été d'introduire le contrôle de version (CVS, parce que je ne savais pas à quel point il était nul!), Mais de nombreux développeurs embauchés après moi n'ont pas pu le faire fonctionner sur leur développement. environnements, donc je ne l'ai pas utilisé. Oh, ai-je mentionné qu'ils n'avaient même pas d'instances locales de l'application en cours d'exécution? Ils ont piraté du code sur le serveur. Et pas de tests automatisés, bien sûr. Je grince des dents quand j'y repense.

Avant cela, j'ai fait du travail de programmation AS / 400 sans contrôle de version. Je ne sais pas si un VCS décent était même disponible pour cet environnement.

Maintenant, j'utilise Git pour tous mes projets individuels, et mes derniers travaux l'ont également utilisé.

CI est une autre affaire. C'est génial d'avoir, et je l'encourage, mais c'est moins essentiel que le contrôle de version, au moins pour les petits projets dans des langages interprétés. Cependant, la plupart de mes emplois récents ont eu des serveurs CI; entre autres, cela signifie que personne ne peut oublier d'exécuter la suite de tests complète avant le déploiement.


«CI est une autre affaire. C'est génial d'avoir, et je l'encourage, mais c'est moins essentiel que le contrôle de version, du moins pour les petits projets dans des langages interprétés. D'accord. CI n'est vraiment nécessaire que lorsque vous effectuez des builds fréquents et / ou complexes et qu'il commence à prendre beaucoup de votre temps, ou que vous souhaitez exécuter une suite de tests, ou que vous souhaitez pouvoir organiser plusieurs branches, etc. un projet PHP avec une douzaine de développeurs, pas de suite de tests, et vous passez en production une fois par semaine, vous voudrez probablement vous concentrer sur un bon flux de travail QA avant de commencer à vous soucier de CI.
siliconrockstar

Et vous voudrez probablement vous concentrer sur une bonne suite de tests avant de commencer à vous soucier de l'assurance qualité ou de toute autre chose.
Marnen Laibow-Koser

Peut-être en théorie, mais si vous utilisez un logiciel open source, à moins qu'il ne soit livré avec une suite de tests, cela est pratiquement impossible. Je n'ai jamais travaillé sur un projet PHP qui avait une couverture de test complète et appropriée, mais chaque projet sur lequel j'ai travaillé a eu un certain niveau d'assurance qualité.
siliconrockstar

@siliconrockstar Je parlais d'avoir une bonne suite de tests pour votre propre code; un niveau approprié de test pour le code de bibliothèque est une tout autre affaire.
Marnen Laibow-Koser

@siliconrockstar Pour ce que ça vaut, la plupart des projets Rails sur lesquels j'ai travaillé ont une excellente couverture de test pour les développeurs (les exceptions essayaient activement de l'améliorer); tous n'ont pas eu un AQ formel. Il est beaucoup moins nécessaire d'avoir un contrôle qualité formel avec de bons tests, bien que ce soit toujours une très bonne idée. Cependant, le développement sans tests en place est incroyablement risqué, c'est pourquoi je dis que l'amélioration des tests devrait être prioritaire par rapport à toute autre chose.
Marnen Laibow-Koser

0

J'en ai certainement rencontré quelques-uns ici et là, mais surtout des petites entreprises. Le problème que je vois le plus souvent, ce sont les entreprises qui disposent en fait de SCM, mais jugent que de nombreux projets sont trop petits ou sans importance pour y être suivis.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.