Pourquoi les grandes entreprises utilisent Perforce?
J'ai entendu parler de certaines grandes entreprises, par exemple Google et Facebook utilisent Perforce
Y a-t-il une raison pour laquelle SVN/Git ne peut pas remplacer Perforce?
La justification est peut-être moins pertinente qu'elle ne l'était autrefois, mais Perforce a tendance à mieux fonctionner sur les grands référentiels que Subversion. C'est l'une des raisons pour lesquelles Microsoft a acquis une licence source pour Perforce pour construire Source Depot; Le référentiel de NT est un monstre, et peu de produits, commerciaux ou autres, pourraient le gérer.
En outre, au moins à un moment donné, les outils visuels pour Perforce étaient bien, bien meilleurs que ceux disponibles (pour ainsi dire) avec Subversion ou Git. Si vous utilisez Meld, ces choses importent peut-être moins qu'autrefois, mais il y a encore quelques choses que Perforce a très bien faites, y compris des visualisations de ramification et de fusion qui, bien que je n'ai pas de mémoire détaillée depuis que cela a été environ 3 ans depuis que j'ai touché Perforce pour la dernière fois, semblait plus sophistiqué que, par exemple, l'approche de Github à cet égard.
Une fois que vous avez utilisé Perforce, vous pouvez comprendre quels sont ses avantages dans la pratique. Ils proposent depuis longtemps une option de serveur gratuit pour deux utilisateurs, et selon les systèmes de gestion de code source avec lesquels vous avez de l'expérience, vous trouverez peut-être le coût de la mise à niveau après que votre équipe l'ait testé pendant un certain temps. Pour les magasins plus petits, cela, ainsi que les effets de réseau des développeurs qui l'ont utilisé et l'ont aimé, c'est pourquoi Perforce finit par obtenir des utilisateurs payants. Contrairement aux remarques cyniques de Dmitri, il n'y a probablement pas grand-chose à gagner et à manger des CTO pour vendre Perforce dans des entreprises avec de petites équipes de développement, mais il est utilisé dans de tels endroits.
La plupart des projets sur lesquels j'ai travaillé en dehors de Microsoft peuvent être raisonnablement bien servis par Git, Mercurial ou Subversion, et je dirais que la majorité des entreprises pour lesquelles j'ai travaillé utilisent l'une de ces options. Mais il existe un point idéal, généralement une combinaison de taille de référentiel, de modèle de branchement et de fusion et d'expérience/historique d'équipe qui amène les gens à utiliser des outils commerciaux. J'ai rarement vu de grands référentiels Git, par exemple. Cela peut ne pas être dû à des limitations intrinsèques de Git; J'admets une ignorance totale de cela. Mais dans certains projets (comme Windows NT), il peut y avoir des limites pratiques aux solutions gratuites.
Je suis raisonnablement compétent avec svn, git et Perforce, à la fois en tant qu'utilisateur et dans la configuration et la maintenance des serveurs.
Pour une entreprise, ou même un seul programmeur comme moi, le contrôle des sources est un coût engagé pour soutenir l'activité lucrative réelle, qui consiste à développer et vendre du code. Il y a donc plusieurs facteurs à considérer:
- Dans quelle mesure cela correspond-il à votre modèle de développement?
- Est-il facile pour les développeurs d'apprendre et d'utiliser?
- Les opérations de routine pour les développeurs sont-elles rapides?
- Le processus d'utilisation est-il une distraction par rapport à leur vrai travail, qui est d'écrire du code?
- Est-il facile à installer et à entretenir?
- Combien cela coûte-t-il d'acheter et d'entretenir?
- Si vous avez besoin d'aide, est-il facile de l'obtenir?
Je vais sauter le détail tl: dr sur les avantages et les inconvénients des systèmes individuels. Il suffit de dire que lorsque je suis retourné à la consultation à temps plein l'année dernière, j'ai passé en revue les trois pour décider lequel me permettrait de gagner le plus d'argent le plus rapidement possible en fournissant des logiciels de qualité à mes clients, et sans nécessiter beaucoup de travail non rémunéré couchait. Quand j'ai pris la considération politique de "FOSS est bon et non-FOSS est mal" hors de l'équation, j'ai fini par chercher une licence Perforce.
Et c'est pourquoi les grandes entreprises choisissent également Perforce.
Voici les détails tl: dr des commentaires, et un peu plus.
L'adressage de svn est facile: par rapport à Perforce, c'est lent. J'ai travaillé dans une entreprise qui faisait du Linux embarqué pour les téléphones portables, et nos sources complètes fonctionnaient à 9 Go; ils ont utilisé Perforce. Une fois que vous avez eu le code, la mise à jour des dernières sources prend normalement quelques secondes sur le LAN, ou quelques minutes via une connexion VPN depuis ma maison. Avec svn, cela aurait été respectivement minutes et heures.
git vs Perforce est plus compliqué. De nombreuses entreprises ont le sentiment qu'elles ont de bonnes raisons commerciales d'utiliser un référentiel centralisé avec contrôle d'accès, de faciliter la validation sur ce site et de faire autre chose - et Perforce correspond parfaitement à ce modèle. Cependant, git encourage positivement les gens à travailler dans une succursale locale, et il n'y a aucun moyen de le faire fonctionner différemment. Un développeur peut travailler entièrement dans une succursale locale et ne jamais s'engager dans le référentiel central - donc si une entreprise ne veut pas que ses employés travaillent de cette façon, Perforce est une meilleure option.
Il y a d'autres problèmes avec git pour certains besoins commerciaux. J'ai travaillé dans une entreprise qui utilisait git, et je ne sais pas combien de fois j'ai entendu cette discussion: "Je souhaite que nous utilisions [un autre VCS], parce que je dois faire [ceci] et je ne peux pas avec git . " "Bien sûr, vous pouvez le faire avec git." "Comment?" "Eh bien, vous devez d'abord écrire un script bash ..." "Peu importe."
Et puis il y a le temps qu'il faut pour remplir initialement un arbre source qui a beaucoup d'histoire. Avec Perforce, parce que l'historique est conservé sur le serveur, vous obtenez simplement les dernières versions de tous les fichiers, donc c'est vraiment rapide - même la configuration de l'arborescence de 9 Go que j'ai mentionnée n'a pris que quelques heures sur un VPN. Avec git, cela peut prendre entre longtemps et éternité. Je dois parfois cloner GTK + ou le git repos du serveur X, et c'est une longue pause déjeuner, ou peut-être l'heure du lit.
Vraiment, c'est une question de bon outil pour le travail. svn fonctionne très bien pour la plupart des efforts open source d'Apple, et serait horrible pour le piratage du noyau. git fonctionne très bien pour GTK +, mais est incroyablement lent pour travailler à l'intérieur de WebKit - l'arborescence source et l'historique sont tout simplement trop énormes (comme j'ai découvert la manière difficile de travailler avec le code du portail svn-to-git de WebKit). Perforce fonctionne bien si vous avez un arbre source géant et avez besoin d'un contrôle centralisé. Chacun d'eux fonctionne bien dans le bon contexte.
GIT en particulier, et SVN dans une certaine mesure ne sont pas si vieux - si vous aviez besoin d'un contrôle de version solide au milieu des années 90, vous deviez presque devenir commercial car SVN était à ses balbutiements et CVS était, eh bien, CVS. Une fois que vous avez beaucoup investi dans un système, le déplacer peut être un ours.
Oh, et les gars qui prennent ces décisions n'interagissent probablement jamais avec le système de contrôle de version, mais ils sont récompensés et mangés par le personnel de vente susmentionné.
Je suis programmeur dans l'industrie des jeux depuis près de 9 ans maintenant, et tous les projets sur lesquels j'ai travaillé ont utilisé Perforce. Je soupçonne qu'il y a quelques éléments qui permettent à Perforce d'être utilisé dans cette industrie particulière.
- Les gens utilisent Perforce depuis longtemps et sont assez à l'aise avec cela, ce qui les rend hésitants à passer à une autre solution. Les décideurs peuvent également hésiter à mettre leur projet de 30 millions de dollars entre les mains d'un logiciel qu'ils n'ont jamais utilisé auparavant.
- De nombreuses entreprises/équipes ont ajouté la prise en charge Perforce à leurs outils internes, ce qui peut nécessiter une quantité importante de travail de mise à jour pour prendre en charge un autre VCS.
- Bien que les programmeurs puissent passer facilement à un autre Git/Hg/SVN, il y a beaucoup moins de membres techniques d'une équipe de développement de jeux, tels que des artistes, des concepteurs et des producteurs. Les mettre à l'aise avec le nouveau système pourrait prendre beaucoup de temps, et je serais prêt à parier qu'ils seraient assez résistants au changement.
Peut-être, peut-être qu'ils aiment Perforce parce que Perforce est meilleur?
- Perforce est rapide. Beaucoup plus rapide que Subversion ou Git.
- La fusion Perforce est meilleure que Subversion ou Git. Git ne fait pas vraiment de fusion et le suivi des versions de Subversion n'est pas si bon, du moins en 1.5.
- Perforce a un excellent support client.
- Perforce associe révision du référentiel de Subversion aux révisions de fichiers individuels. Perforce vous permet d'afficher les révisions du référentiel via listes de modifications ou les révisions de fichiers individuels.
- Perforce fait un bien meilleur travail avec plusieurs listes de modifications que Subversion. Les listes de modifications de Subversion sont en quelque sorte une réflexion après coup et je connais peu de personnes qui l'utilisent. Perforce est intégré. Si vous déplacez un fichier modifié de la liste de modifications par défaut, il n'est pas accidentellement validé.
- Perforce vous permet de spécifier la disposition de votre répertoire de travail. Par exemple, si vous avez une arborescence de répertoires de code source standard, mais que certains clients ont une source personnalisée, vous pouvez superposer la source personnalisée sur l'arborescence standard. Vous pouvez facilement effectuer des extractions clairsemées en spécifiant uniquement les éléments que vous souhaitez extraire.
D'accord, avant de penser que je suis un fanboi de Perforce, la dernière fois que j'ai recommandé Perforce à une entreprise remonte à plus de sept ans. Perforce coûte 800 $ par licence - ce qui est bon marché par rapport à ClearCase, mais beaucoup plus cher que Subversion. J'ai du mal à justifier Perforce sur Subversion.
De plus, la plupart des développeurs sont habitués à Subversion. Ils ne veulent pas apprendre Perforce qui a une façon de travailler différente de Subversion. Dans Perforce, vous devez créer un client et vous devez marquer les fichiers à modifier avant de pouvoir les modifier. Vous n'avez pas à le faire avec Subversion.
Il y a aussi moins d'intégrations avec Perforce sur Subversion. Cela est dû en partie à l'utilisation de client. Il ne fonctionne tout simplement pas bien avec VisualStudio ou même Hudson. Cela est dû en partie au fait que Perforce doit créer les intégrations client.
Il y a un coût pour une licence propriétaire appelé le coût administratif. Imaginez si vous pouviez acheter un logiciel pour 1,00 $ par utilisateur. Heck, faisons-en deux bits. Des milliers de licences ne vous coûteraient que 250 $.
Maintenant, vous avez besoin d'une personne à temps plein qui gère la licence. Un technicien moyen reste dans une entreprise pendant environ 2 ans. Cela signifie que 500 personnes partiront chaque année et 500 autres viendront. Chaque semaine, dix personnes doivent changer de licence. Ensuite, il y a des moments où le projet reprend et vous avez besoin de 250 licences supplémentaires. Ceux-ci doivent être commandés, saisis et conservés. Cela peut prendre des semaines.
C'est pourquoi de nombreuses entreprises commerciales sont passées à l'open source. Ce n'est pas le coût d'une licence. Vous payez un développeur 150 000 $ par an, qu'est-ce que 800 $ de plus pour une licence Perforce? Il gère cette licence. Perforce a fière allure par rapport à ClearCase: plus rapide, plus facile, moins cher, mieux. Mais contre Subversion? Perforce pourrait être plus rapide et peut-être mieux, mais est-ce 800 $ mieux? Gère-t-elle mieux la licence? N'utilise-t-il pas mieux l'outil souhaité?
C'est pourquoi Perforce peut avoir des problèmes.
Git n'est pas l'outil universel. Cela fonctionne très bien dans les circonstances où vous ne voulez pas un contrôle centralisé de qui a accès à un référentiel. Mais, cela peut être pénible dans de nombreuses circonstances. La façon dont je le formule est la suivante:
- Vous exécutez un projet open source. Seriez-vous heureux ou contrarié si un million de personnes avaient une copie de votre référentiel entier?
- Vous dirigez un bureau de négociation financière qui utilise un logiciel propriétaire pour obtenir un avantage sur vos concurrents. Seriez-vous heureux ou contrarié si un million de personnes avaient une copie de votre référentiel entier?
Si vous effectuez des builds centralisés, vous avez besoin de tout le monde d'utiliser un seul référentiel de toute façon. Quel est l'avantage d'un système distribué dans ces circonstances? En fait, cela peut encourager les gens à travailler hors ligne. Les développeurs peuvent simplement s'en aller à leur guise et ne rien engager avant la dernière minute. Ensuite, vous passez deux jours effrénés à essayer de tout faire fonctionner à nouveau.
Je ne suis pas contre Git. J'ai recommandé Git dans de nombreux cas. Il s'agit notamment d'équipes distribuées avec de mauvaises connexions les unes aux autres, ou des endroits où vous ne souhaitez pas suivre toutes les personnes ayant accès au référentiel source.
Par exemple, un département d'informatique d'université voulait que ses élèves utilisent le contrôle de code source et y mettent leur code pour que les enseignants puissent le consulter. Bonne idée. Trop d'enfants quittent l'université sans comprendre les procédures de construction et de développement standard. J'ai recommandé Git.
En utilisant Git, l'administrateur du référentiel n'a qu'à accepter les commits de ses collègues professeurs. Ils n'ont pas à se soucier des étudiants individuels. Les professeurs peuvent permettre aux étudiants de s'engager dans leur version du référentiel. Les étudiants peuvent travailler en groupes et chaque groupe peut partager sa version du référentiel.
Si le collège utilisait Subversion, quelqu'un devrait connaître tous les étudiants et leur donner tous accès au référentiel central. Ils devraient gérer qui peut vérifier quoi et où. Si un professeur assignait un projet de groupe, cela devrait être configuré et géré. Vous auriez besoin d'une personne à plein temps pour gérer cela.
Ce n'est pas un match de football où une équipe est meilleure qu'une autre. Les outils fonctionnent de différentes manières et chacun a ses avantages et ses inconvénients. Perforce est un excellent outil. Malheureusement, des circonstances se sont développées qui font qu'il est difficile de recommander.
Git est génial, mais je reviens toujours à Subversion pour mon référentiel personnel. Après tout, je ne le partage pas, et Subversion est simplement plus facile à utiliser. J'utilise Git pour un travail personnel si j'ai une petite équipe car je n'ai pas à garder mon référentiel à plein temps sur Internet. Pour la plupart des sites commerciaux, je trouve toujours que Subversion fonctionne le mieux. Mais, il y a des circonstances où Git brille.
Parce que des outils comme Perforce ont des vendeurs de vin et de personnes en charge des achats, contrairement à Git. Bien sûr, c'est juste le côté cynique de ma conversation, mais c'est un cynisme provoqué en voyant le processus de près.
Juste pour être parfaitement clair: je ne pas signifie que chaque fois que vous voyez votre CIO trébucher ivre dans le couloir, attendez-vous à utiliser un nouveau système de versioning au cours du prochain trimestre. Juste qu'il y a un décalage dans de nombreuses organisations entre l'utilisation et l'acquisition. Bien sûr, il existe d'autres raisons pour lesquelles les entreprises utilisent Perforce: par exemple, elles peuvent déjà avoir investi massivement dans sa mise en œuvre dans leur flux de travail. Mais généralement --- et cette question est très générale --- il n'y a aucun avantage fonctionnel à ne pas utiliser les outils FOSS.
Je ne sais pas si la corruption `` vin et dîner '' est toujours applicable, mais pour la plupart des managers lorsqu'ils décident de trouver un produit, ils liront dans diverses publications (destinées à la direction) et consulteront les brochures et dépliants vantant le produit. vertus.
Devinez quoi, les produits FOSS ne figurent pas dans ces endroits!
Il est donc presque acquis que la plupart des décisions de gestion-achats sont motivées par la publicité et le marketing. Ils peuvent effectuer des évaluations, mais de plusieurs de ces produits.
L'autre raison est due à la maturité. Certains produits que nous utilisons aujourd'hui ne sont suffisamment stables que récemment pour une utilisation professionnelle sérieuse, certains n'ont pas d'options de support, d'autres n'ont pas fait leurs preuves en tant que solutions commerciales. Ce sont des choses importantes à considérer (même si en tant que technicien, j'évaluerai volontiers les solutions FOSS si le risque de les utiliser et de les faire échouer est minime pour maintenir l'entreprise en marche) et certains gestionnaires hésitent à juste titre à ne pas les avoir autour. Ils sont responsables devant leurs patrons et se sentiront beaucoup plus à l'aise s'il y a une organisation de support derrière le produit - vous en avez un pour votre entreprise après tout.
Enfin, alors que de nombreux produits FOSS ont un support derrière eux (pensez Collabnet ou Wandisco pour SVN), il a toujours la réputation de `` made by geeks in their back bedroom ''. Nous savons tous que c'est généralement b * * ** t et les meilleurs logiciels libres sont incroyablement compétitifs avec les offres commerciales, mais mon manager doit encore être convaincu. peut-être qu'il ne réalise tout simplement pas la différence entre les produits FOSS immatures et matures; peut-être qu'il s'en fiche.
Quoi qu'il en soit, Perforce est un bon SCM, il n'y a aucune raison de ne pas le choisir. Je pourrais dire la même chose pour les autres SCM, mais là encore, je ne peux dire que de mauvaises choses à propos de certains autres, et j'ai encore des cauchemars en ce qui concerne certains produits.
Probablement la même raison pour laquelle mon entreprise refuse d'utiliser beaucoup de logiciels open source (pas que je suis d'accord):
Quand quelque chose ne va pas, ils veulent quelqu'un qu'ils peuvent appeler et crier dessus.
Alors que toutes les réponses parlent de grandes entreprises utilisant P4 (et elles expliquent pourquoi Google a utilisé P4), l'une des principales raisons pour lesquelles Google continue d'utiliser Perforce est que Perforce vous permet de vérifier un sous-arbre du dépôt alors que vous ne pouvez pas le faire avec Git. Avec de grands référentiels comme Google, cela a fait une énorme différence.
Et d'après ce que j'ai entendu, Facebook utilise SVN et Git-SVN
Parce que SVN est, eh bien, SVN et Perforce (il y a 4 ans en comparant les outils) fait certaines choses mieux que SVN . (Je pense que la ramification en fait partie.)
Et GIT est un Dvcs, comme dans distribué . Pour les équipes de l'entreprise, la partie distribuée pourrait bien être quelque chose dont on ne se soucie ni ne souhaite.
Une autre raison pour laquelle les grandes entreprises ont tendance à acheter de gros systèmes de contrôle de version "d'entreprise":
Les cadres intermédiaires et supérieurs des services informatiques considèrent VCS comme quelque chose que chaque projet utilise, ou vous pouvez appliquer son utilisation. Une fois que vous avez imposé l'utilisation d'un VCS, pourquoi ne pas y mettre également un petit "processus"? Je veux dire, vous avez la possibilité de spécifier un système "à l'échelle de l'entreprise", pourquoi ne pas le placer sous contrôle central, et d'ajouter la "reprise après sinistre" et certaines "fonctionnalités de flux de travail" afin que vous puissiez dire "Nous sommes CMJ Level StraightJacket conforme! ". Un VCS est tout simplement trop facile à atteindre pour mettre des fonctionnalités d'application de workflow, c'est à cela qu'il se résume.
En ce qui concerne le choix de certains logiciels croustillants ickky-poo (Serena Dimensions), il est dit que quelques rondes de Bikini Golf aux Bahamas avec quelques 20 vendeuses peuvent convaincre un directeur ou un vice-président de presque n'importe quoi.
Les grandes entreprises ont besoin d'un modèle centralisé quelconque. Une fois que les développeurs ont terminé le développement, il est remis au support client. Voulez-vous vraiment être dans la peau des supports quand ils doivent passer au peigne fin les développeurs 50 à 50 répartis? Et les builds sont effectués sur la base du référentiel central, les builds doivent toujours, toujours, toujours être traçables et reproductibles. Vous apprenez cela la première fois que vous êtes traduit en justice pour une violation de brevet stupide.
Git ne fonctionne pas aussi bien dans ce modèle. Si vous avez une petite entreprise, ou une avec un accès VPN médiocre, c'est là que ça brille vraiment.
La raison pour laquelle la plupart des grandes entreprises utilisent Perforce est qu'il y a plus de professionnels dans le service informatique qui ont beaucoup de connaissances à ce sujet et ont des années d'expérience dans le dépannage des problèmes qui y sont liés.
Je pense qu'à l'avenir, les entreprises pourraient commencer à s'éloigner de Perforce et davantage vers GIT ... la plupart des développeurs que je connais semblent le préférer !! Consultez également http://whygitisbetterthanx.com/#git-is-fast pour plus de preuves sur les raisons pour lesquelles Perforce pourrait ne pas être aussi dominant dans les années à venir !!
Il y a quelques temps, nous sommes passés d'un ensemble de VCS (je sais avec certitude que RCS, CVS, ClearCase, Perforce ont déjà été utilisés, il pourrait y en avoir d'autres aussi) pour Perforce en tant que système unique en cours d'utilisation. Ce n'était pas un petit projet: la migration a pris plus d'un an. L'équipe (je n'en faisais pas partie) en charge a évalué plusieurs VCS, et au moins git et svn ont été considérés ainsi que ceux déjà utilisés. Si je me souviens de leur rapport, ils ont filtré les outils sans les fonctionnalités nécessaires et ont ensuite considéré:
performances sur une utilisation typique, en particulier pour les sites distants
besoins en ressources
importance des changements nécessaires dans l'habitude de travail
disponibilité et coût du support
et Perforce a été un gagnant assez clair dans l'ensemble. git était légèrement meilleur pour le premier point, mais désavantagé pour les autres.
Il était une fois il n'y a pas si longtemps (quand le IDE était appelé VI), les seuls systèmes gratuits (open source) étaient CVS, RCS et SCCS.
- Aucun de ceux-ci ne pourrait même bien faire face à un fichier renommé.
- Ils n'ont pas enregistré les fusions, donc si deux branches étaient activement travaillées, il était très difficile de fusionner jusqu'à ce que le travail soit terminé sur une branche.
- Ils ne se sont pas bien adaptés à de très grandes bases de code
- Ils n'ont pas fourni le niveau de contrôle d'accès et d'informateur de processus souhaité par les grands projets.
Il y avait beaucoup de systèmes de contrôle de code source commerciaux, la plupart d'entre eux étaient fournis par un fournisseur de machine unique (IBM, DEC, HP, etc.) et ne fonctionnaient que sur leur matériel.
Ensuite, quelques sociétés ont déclaré qu'elles vendaient le contrôle de code source commercial multiplateforme, notamment Perforce et ClearCase.
ClearCase a été construit sur RPC qui ne fonctionnait pas bien sur les réseaux étendus (mais seul sur Internet) en raison du fait que de nombreux petits paquets réseau étaient "déclenchés", IBM et rationnel ont également considéré ClearCase comme une "vache à lait" et ne l'ont jamais montré beaucoup amour.
Ainsi, le seul "ancien" système de contrôle de code source commercial qui est encore couramment utilisé est Perforce. Une fois que perforce est utilisé et intégré dans les systèmes de construction et les systèmes de suivi des bogues, il y a très peu avantage à court terme pour une entreprise de passer à autre chose.
Donc, pour résumer, forcément a obtenu le "pied dans la porte" quand il n'y avait pas beaucoup d'autres options, et ils n'ont pas encore assez gâché pour amener les gens à s'en éloigner.