Pourquoi les grandes entreprises utilisent Perforce? [fermé]

J'ai entendu parler de certaines grandes entreprises, par exemple Google et Facebook utilisent Perforce.

Existe-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 auparavant, 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 auprès de Perforce pour créer 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 une fois, les outils visuels de Perforce étaient bien meilleurs que ceux disponibles (pour ainsi dire) avec Subversion ou Git. Si vous utilisez Meld, ces choses importent peut-être moins qu'avant, mais Perforce a très bien réussi à bien faire certaines choses, notamment les visualisations de ramifications et de fusions, bien que je n'ai pas de mémoire détaillée depuis. Environ trois ans après avoir touché Perforce pour la dernière fois, cela semblait plus sophistiqué que l'approche de Github, par exemple.

Une fois que vous avez utilisé Perforce, vous comprendrez quels sont ses avantages dans la pratique. Ils offrent depuis longtemps une option de serveur gratuit à deux utilisateurs et, en fonction des systèmes de gestion de code source avec lesquels vous avez de l'expérience, vous pouvez constater que le coût de la mise à niveau en vaut la peine, après avoir été testé par votre équipe pendant un certain temps. Pour les plus petits magasins, c’est pour cette raison, ainsi que pour les effets réseau des développeurs qui l’ont utilisé et qui l’a plu, que Perforce finit par avoir des utilisateurs payants. Il n’ya probablement pas beaucoup de gens qui mangent et dînent des CTO pour vendre Perforce dans des entreprises avec de petites équipes de développement, contrairement aux propos cyniques de Dmitri, mais cela 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 d’intérêt, généralement une combinaison de la taille du référentiel, du modèle de branchement et de fusion, et de l’expérience / de l’histoire d’équipe qui conduit les utilisateurs à utiliser des outils commerciaux. J'ai rarement vu de grands référentiels Git, par exemple. Cela n’est peut-être pas dû aux limitations intrinsèques de Git; Je reconnais l'ignorance totale de cela. Mais dans certains projets (tels que Windows NT), il peut exister des limites pratiques aux solutions libres.

Je maîtrise assez bien svn, git et Perforce, tant en tant qu'utilisateur que pour la configuration et la maintenance des serveurs.

Pour une entreprise, voire un programmeur isolé comme moi, le contrôle de la source représente un coût supporté par l'activité génératrice de revenus, qui consiste à développer et à vendre du code. Il y a donc plusieurs facteurs à prendre en compte:

• 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 de leur vrai travail, qui consiste à écrire du code?
• Est-ce facile à installer et à entretenir?
• Combien coûte l'achat et l'entretien?
• Si vous avez besoin d'aide, est-il facile de l'obtenir?

Je vais ignorer les détails sur les avantages et les inconvénients des systèmes individuels. Je me contenterai de dire que lorsque je suis revenu à 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 possible en livrant des logiciels de qualité à mes clients, sans nécessiter beaucoup d’impayés. rigoler. Lorsque j'ai pris en compte le fait que "les logiciels libres sont bons et que les non-logiciels libres sont diaboliques", je me suis retrouvé à chercher une licence Perforce.

Et c'est pourquoi les grandes entreprises choisissent également Perforce.

Voici les détails des commentaires, plus un peu plus.

S'adresser à svn est facile: comparé à Perforce, il est lent. J'ai travaillé dans une entreprise qui implémentait Linux pour les téléphones cellulaires et nos sources complètes utilisaient 9 Go; ils ont utilisé Perforce. Une fois que vous avez eu le code, la mise à jour des sources les plus récentes prend normalement quelques secondes sur le réseau local, ou quelques minutes via une connexion VPN de chez moi. Avec svn, c'auraient été minutes et heures respectivement.

git vs. Perforce est plus compliqué. De nombreuses entreprises ont le sentiment qu’elles ont de bonnes raisons d’utiliser un référentiel centralisé avec contrôle de l’accès, de faciliter l’engagement et de ne rien faire d’autre - et Perforce correspond parfaitement à ce modèle. Cependant, git encourage les gens à travailler dans une branche locale et il n’ya aucun moyen de le faire fonctionner différemment. Un développeur peut travailler entièrement dans une branche locale et ne jamais s'engager dans le référentiel central. Par conséquent, si une entreprise ne veut pas que ses collaborateurs travaillent de cette manière, Perforce est une meilleure option.

Il existe d'autres problèmes avec git pour certains besoins de l'entreprise. J'ai travaillé dans une entreprise qui utilisait git, et je ne sais pas combien de fois j'ai entendu cette discussion: "J'aurais aimé utiliser [un autre VCS], car je dois le faire et je ne peux pas avec git . " "Bien sûr, tu peux le faire avec git." "Comment?" "Eh bien, vous devez d'abord écrire un script bash ..." "Ne faites pas attention."

Et puis il y a le temps qu'il faut pour peupler une arborescence source qui a beaucoup d'histoire. Avec Perforce, l'historique étant conservé sur le serveur, vous ne disposez que des versions les plus récentes de tous les fichiers. Il est donc très rapide: même configurer tout cet arbre de 9 Go que j'ai mentionné ne prend que quelques heures sur un VPN. Avec git, cela peut prendre entre un long moment et une éternité. Je dois parfois cloner GTK + ou le dépôt git de serveur X, et c'est une longue pause pour le déjeuner, ou peut-être l'heure du coucher.

En réalité, il s’agit du bon outil pour le poste. svn fonctionne bien pour la plupart des efforts open source d’Apple et serait affreux pour le piratage du noyau. git fonctionne très bien pour GTK +, mais est incroyablement lent pour travailler dans WebKit - l’arbre source et l’historique sont tout simplement trop énormes (car j’ai découvert la difficulté de travailler avec du 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, n’est pas si vieux - si vous aviez besoin d’un contrôle de version solide au milieu des années 90, vous deviez presque vous lancer dans la commercialisation, car SVN en était à ses balbutiements et CVS était bien CVS. Une fois que vous avez beaucoup investi dans un système, le déplacer peut être un ours.

Oh, et les personnes qui prennent ces décisions n'interagissent probablement jamais avec le système de contrôle de version, mais se font bousculer par le personnel des ventes susmentionné.

Je suis programmeur dans l'industrie du jeu vidéo depuis presque 9 ans maintenant, et chaque projet sur lequel j'ai jamais travaillé a utilisé Perforce. Je soupçonne que Perforce est toujours utilisé dans ce secteur.

• Les gens utilisent Perforce depuis longtemps et le maîtrisent assez bien, ce qui les rend hésitants à passer à une autre solution. Les décideurs peuvent également hésiter à confier leur projet de 30 millions de dollars à un logiciel qu’ils n’ont jamais utilisé auparavant.
• De nombreuses entreprises / équipes ont ajouté le support Perforce à leurs outils internes, ce qui peut nécessiter beaucoup de travail de mise à jour pour prendre en charge un autre VCS.
• Bien que les programmeurs puissent facilement basculer vers un autre Git / Hg / SVN, il existe de nombreux membres moins techniques dans une équipe de développement de jeux, tels que des artistes, des concepteurs et des producteurs. Les familiariser avec le nouveau système risque de prendre beaucoup de temps, et je serais prêt à parier qu'ils seraient très réticents au changement.

Peut-être qu'ils aiment peut-être Perforce parce que Perforce est meilleur?

• Perforce est rapide. Beaucoup plus rapide que Subversion ou Git.
• La fusion forcée est meilleure que Subversion ou Git. Git ne fusionne pas vraiment et le suivi de version de Subversion n'est pas très bon, du moins dans la version 1.5.
• Perforce dispose d'un excellent support client.
• Perforce combine la révision de référentiel de Subversion avec les révisions de fichiers individuels. Perforce vous permet d'afficher les révisions du référentiel via des listes de modifications ou des révisions de fichiers individuels.
• Perforce fait beaucoup mieux 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 d’utilisateurs. Perforce est intégré. Si vous déplacez un fichier modifié de la liste de modifications par défaut, il ne sera pas validé par accident.
• Perforce vous permet de spécifier la disposition de votre répertoire de travail. Par exemple, si vous avez une arborescence de répertoire 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 achats clairsemés en spécifiant uniquement les éléments que vous souhaitez effectuer.

D'accord, avant de penser que je suis un Perforce Fanboi, la dernière fois que j'ai recommandé Perforce à une entreprise, c'était il y a plus de sept ans. Perforce coûte 800 dollars par licence, ce qui est peu coûteux par rapport à ClearCase, mais beaucoup plus cher par rapport à Subversion. J'ai du mal à justifier Perforce plutôt que 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 marquer les fichiers à modifier avant de pouvoir les modifier. Vous n'avez pas à faire cela avec Subversion.

Il y a également moins d'intégrations avec Perforce que Subversion. Cela est en partie dû à l'utilisation du client . Cela 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 à la licence propriétaire appeler les coûts administratifs. Imaginez si vous pouviez obtenir une licence pour un logiciel à 1,00 USD par utilisateur. Heck, faisons en deux bits. Des milliers de licences ne vous coûteraient que 250 dollars.

Maintenant, vous avez besoin d'une personne à temps plein pour gérer la licence. Un ouvrier technique moyen reste dans une entreprise pendant environ deux ans. Cela signifie que 500 personnes partiront chaque année et que 500 autres viendront. La licence doit être changée chaque semaine par dix personnes. Ensuite, il y a des moments où le projet démarre et où vous avez besoin de 250 licences supplémentaires. Ceux-ci doivent être commandés, entrés et maintenus. Cela peut prendre des semaines.

C'est pourquoi de nombreuses entreprises commerciales ont opté pour l'open source. Ce n'est pas le coût d'une licence. Vous payez 150 000 dollars par an à un développeur, mais 800 dollars de plus pour une licence Perforce? C'est gérer cette licence. Perforce est bien comparé à 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-il mieux la licence? N'est-ce pas mieux d'utiliser un outil souhaité?

C'est pourquoi Perforce peut avoir des problèmes.

Git n'est pas l'outil ultime. Cela fonctionne très bien dans les cas où vous ne voulez pas de contrôle centralisé des personnes ayant accès à un référentiel. Mais, cela peut être une douleur dans de nombreuses circonstances. La façon dont je le dis est la suivante:

1. Vous exécutez un projet open source. Seriez-vous heureux ou contrarié si un million de personnes possédaient une copie complète de votre référentiel?
2. Vous exploitez une table de négociation financière qui utilise un logiciel propriétaire pour avoir un avantage sur vos concurrents. Seriez-vous heureux ou contrarié si un million de personnes possédaient une copie complète de votre référentiel?

Si vous effectuez des générations centralisées, vous devez de toute façon utiliser un seul référentiel. Quel est l'avantage d'un système distribué dans cette situation? En fait, cela peut encourager les gens à travailler hors ligne . Les développeurs peuvent simplement partir à leur guise et ne rien commettre avant la dernière minute. Ensuite, vous passez deux jours frénétiques à essayer de tout remettre en marche.

Je ne suis pas contre Git. J'ai recommandé Git dans de nombreux cas. Celles-ci incluent des équipes distribuées ayant 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'un collège souhaitait que ses étudiants utilisent le contrôle de source et y placent leur code pour que les enseignants puissent l'examiner. Bonne idée. Trop d'enfants quittent l'université sans comprendre les procédures standard de construction et de développement. J'ai recommandé Git.

En utilisant Git, l'administrateur du référentiel n'a qu'à prendre des commits de ses collègues professeurs. Ils n'ont pas à s'inquiéter des étudiants individuels. Les professeurs peuvent permettre aux étudiants de s’engager sur leur version du référentiel. Les étudiants peuvent travailler en groupes et chaque groupe peut partager sa version du référentiel.

Si l'université 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 attribue un projet de groupe, celui-ci devra être configuré et géré. Il vous faudrait une personne à temps plein 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, les circonstances sont devenues difficiles à recommander.

Git est génial, mais je continue de faire appel à Subversion pour mon référentiel source personnel. Après tout, je ne le partage pas et Subversion est simplement plus facile à utiliser. J'utilise Git pour le travail personnel si j'ai une petite équipe, car je n'ai pas besoin de garder mon référentiel actif à 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.

Je ne sais pas si la corruption «wine and dine» est toujours applicable, mais pour la plupart des gestionnaires, lorsqu'ils décident de trouver un produit, ils la liront dans diverses publications (destinée à la direction) et consulteront les brochures et dépliants vantant le produit. les vertus.

Devinez quoi, les produits FOSS ne figurent pas dans ces endroits!

Il est donc presque évident que la plupart des décisions d’achat de la direction sont dictées par la publicité et le marketing. Ils peuvent effectuer des évaluations, mais de plusieurs de ces produits.

L'autre raison est due à l'échéance. Certains produits que nous utilisons aujourd'hui ne sont assez stables que depuis peu 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 éléments importants à prendre en compte (bien que, en tant que technicien, j’évaluerai volontiers les solutions FOSS si le risque de les utiliser et de les empêcher de les utiliser est minime pour le bon fonctionnement de l’entreprise) et certains gestionnaires craignent à juste titre de ne pas les avoir. Ils sont responsables devant leurs patrons et se sentiront beaucoup plus à l'aise s'il existe une organisation de soutien derrière le produit - vous en avez une pour votre entreprise, après tout.

Enfin, bien que de nombreux produits FOSS aient un support derrière eux (pensez à Collabnet ou à Wandisco pour SVN), ils ont tout de même la réputation de 'made by geeks in leur back bedroom'. Nous savons tous que c'est généralement b * * ** t et que le meilleur FOSS rivalise incroyablement bien avec les offres commerciales, mais mon responsable doit encore être convaincu. peut-être n’at-il pas conscience de 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 que dire du mal de certains autres, et faire encore des cauchemars en ce qui concerne certains produits.

Parce que des outils comme Perforce ont des vendeurs de vin et des personnes en charge des achats, contrairement à Git. Bien sûr, ce n’est que mon côté cynique quand je parle, mais c’est un cynisme provoqué par le fait de voir le processus de plus près.

Soyons clairs: je ne veux pas dire que chaque fois que vous voyez votre DSI sombrer dans l’ivresse dans le couloir, attendez-vous à utiliser un nouveau système de gestion des versions le trimestre prochain. Il existe simplement un décalage entre l'utilisation et l'acquisition dans de nombreuses organisations. Bien entendu, les entreprises utilisent Perforce pour d'autres raisons: par exemple, elles ont peut-être déjà beaucoup investi 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’ya aucun avantage fonctionnel à ne pas utiliser les outils FOSS.

Probablement la même raison pour laquelle mon entreprise refuse d’utiliser beaucoup de logiciels open source (même si je ne suis pas d’accord):

Quand quelque chose ne va pas, ils veulent quelqu'un à qui 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 d'extraire un sous-arbre du rapport alors que vous ne pouvez pas le faire avec Git. Avec des dépôts à source importante comme Google, cela a fait une énorme différence.

Et autant que j'ai entendu, Facebook utilise SVN et Git-SVN

Parce que SVN est bien, SVN, et Perforce (il y a quatre ans, quand on comparait des outils) fait mieux que SVN . (Je pense que ramifier est l'un d'entre eux.)

Et GIT est un DVD, comme dans distribué . Pour les équipes de la société, la partie distribuée pourrait bien être quelque chose que ni les soins ni les désirs ne visent.

Une autre raison pour laquelle les grandes entreprises ont tendance à acheter de gros systèmes de contrôle de version "entreprise":

Dans les départements informatiques, les cadres moyens et supérieurs considèrent VCS comme un outil que chaque projet utilise, ou que vous pouvez imposer son utilisation. Une fois que vous avez imposé l’utilisation d’un VCS, pourquoi ne pas y inclure é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 l'obtenir sous contrôle central, et ajouter "reprise après sinistre" et quelques "fonctionnalités de flux de travail" afin que vous puissiez dire "Nous sommes au niveau CMM conforme! ". Un VCS est simplement une cible trop facile à intégrer pour mettre en œuvre des fonctionnalités d’application du flux de travail.

En ce qui concerne le choix de certains logiciels croustillants et crasseux (Serena Dimensions), il est dit que quelques manches de Bikini Golf aux Bahamas avec une vingtaine de membres du personnel de vente peuvent convaincre un directeur ou un vice-président de n'importe quoi.

Les grandes entreprises ont besoin d’un modèle centralisé. Une fois que les développeurs ont terminé leur développement, il est transféré au support client. Voulez-vous vraiment être dans la peau du support quand ils doivent passer au peigne fin dans les dépôts de développeurs distribués 50-200? Et les builds sont basés sur le 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 poursuivi en justice pour violation stupide de brevet.

Git ne fonctionne pas aussi bien dans ce modèle. Si vous avez une petite entreprise ou une entreprise avec un accès VPN faible, c'est là que ça brille vraiment.

Une des raisons pour lesquelles la plupart des grandes entreprises utilisent Perforce est peut-être qu’il ya plus de professionnels dans le service informatique qui ont beaucoup de connaissances à ce sujet et qui ont des années d’expérience en matière de résolution de problèmes.

Je pense qu'à l'avenir, les entreprises pourraient commencer à s'éloigner de Perforce et plus encore de 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 suis sûr que RCS, CVS, ClearCase, Perforce étaient utilisés auparavant, il pourrait en exister d'autres) à Perforce en tant que système unique utilisé. Ce n'était pas un petit projet: la migration a pris plus d'un an. L'équipe en charge (je n'en faisais pas partie) a évalué plusieurs VCS, et au moins git et svn ont été pris en compte, 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 pris en compte:

• performances sur utilisation typique, en particulier pour les sites distants

• besoins en ressources

• importance des changements nécessaires dans l'habitude de travail

• support et disponibilité

et Perforce était un gagnant assez clair dans l'ensemble. git était légèrement meilleur pour le premier point, mais désavantageux pour les autres.

Il était une fois, il n'y a pas si longtemps (lorsque l'EDI s'appelait VI), les seuls systèmes libres (open source) étaient CVS, RCS et SCCS.

• Aucun de ceux-ci ne pourrait même gérer un fichier renommé.
• Ils n’enregistraient pas les fusions. Par conséquent, si deux branches étaient en activité, il était très difficile de les fusionner jusqu’à la fin des travaux sur une branche.
• Ils n'ont pas bien évolué vers de très grandes bases de code
• Ils ne fournissaient pas le niveau de contrôle d'accès et d'informateur requis par les grands projets.

Il existait de nombreux systèmes de contrôle de code source commerciaux, la plupart d'entre eux étant fournis par un seul fournisseur de machines (IBM, DEC, HP, etc.) et fonctionnant uniquement sur leur matériel.

Ensuite, quelques sociétés ont déclaré vendre le contrôle de code source commercial multiplate-forme, notamment Perforce et ClearCase.

ClearCase a été construit sur RPC qui ne fonctionnait pas bien sur les réseaux étendus (Internet seul cependant) en raison de nombreux «petits paquets réseau» «trébuchés», IBM et rational ont également vu ClearCase comme une «vache à lait» et ne l'ont jamais beaucoup montré. l'amour.

Ainsi, le seul «ancien» système de contrôle de code source commercial encore utilisé couramment est Perforce. Une fois que perforce est effectivement utilisé et intégré dans les systèmes de construction et les systèmes de suivi des bogues, il n’ya que très peu d’ avantages à court terme pour une entreprise de passer à autre chose.

Donc, pour résumer, nous avons forcément eu le "pied dans la porte" quand il n'y avait pas beaucoup d'autres options, et ils n'ont pas encore suffisamment gâché pour inciter les gens à s'en sortir .