Pourquoi les grandes sociétés financières / d'assurance devraient-elles utiliser git et / ou github

Je travaille pour une grande entreprise (30 000 employés) dans le secteur de la finance / assurance. Bien que "l'informatique" ne soit pas notre objectif principal, soyons honnêtes, ce sont des industries axées sur l'information et les entreprises qui ont le meilleur avantage technologique semblent aller plus vite.

Il existe de nombreuses équipes de développement logiciel dans mon entreprise. Ils sont partout sur la carte avec contrôle de version, sans parler des langages / frameworks utilisés. Certains n'utilisent aucun (je sais), certains utilisent PVCS, certains utilisent VSS et les plus éclairés utilisent SVN.

Je veux apporter du git à mon entreprise. Plus précisément, je veux apporter GitHub (référentiels privés). Je connais les bonnes personnes à qui en parler, mais soyons honnêtes encore une fois, des mouvements drastiques comme celui-ci sont généralement abattus dans les grandes entreprises en raison de vagues problèmes de sécurité ou du fait qu'aucun de nos concurrents ne l'utilise (et je peux ne citer que jQuery, Ruby on Rails, Facebook, etc. comme références).

Voici donc ma question. Quelles sont les raisons les plus convaincantes pour lesquelles une grande entreprise devrait lentement et délibérément passer de PVCS / VSS / SVN à une solution git hébergée comme GitHub (repo privé). Bien sûr, une partie de mon plan implique un POC pour un projet de développement non essentiel.

Il y a quelques choses qui pourraient me préoccuper, en tant que tierce partie désintéressée. Alors laissez-moi vous poser quelques questions auxquelles vous feriez mieux de vous préparer à répondre (à votre service informatique):

• Tout contrôle de version est meilleur que rien. Nous avons l'embarras du choix, quel est le problème avec ceux-ci?
• Contrôle de version distribué? Qu'est-ce que c'est? Comment contrôlons- nous cela?
• Combien ça coûte? Pas seulement le logiciel, mais les serveurs, les licences, la maintenance, etc.
• Je ne fais pas confiance à GitHub, ni à aucun hébergement externalisé. Nous devons tout faire en interne. Pourquoi ne pouvons-nous pas configurer notre propre serveur?
• Pouvons-nous l'exécuter sous Windows? Nous devons le garder sur notre base actuelle, vous savez.
• Comment sécurisons-nous la chose? SVN nous obtenons, mais cela me fait peur.

Ce sont les toutes premières questions qui se poseront. En ce qui concerne VSS et PVCS, vous pouvez probablement trouver un tas d'arguments raisonnablement bons (comme l'historique des versions corrompant VSS). SVN sera un peu plus difficile. Je recommande fortement de se concentrer sur les capacités de fusion de GIT, et recommande également de garder un esprit ouvert sur Mercurial. Chaque argument pour GIT est également un argument pour Mercurial - et Mercurial a un support Windows plus mature.

La sécurité est d'une importance capitale pour les institutions financières et gouvernementales. Ils seront extrêmement résistants aux ressources hébergées en externe. Du point de vue de la gestion des risques, réfléchissez à ce qui pourrait arriver si quelqu'un piratait GitHub et volait le code source, ou découvrait la vulnérabilité de sécurité documentée dans l'outil de suivi des problèmes. Ce serait dévastateur pour l'entreprise. Du point de vue de la gestion pure, si l'entreprise est légalementtenus de vous payer pour chaque heure de travail, comment peuvent-ils contrôler si vous travaillez à domicile lorsque les ressources sont en dehors de leur réseau VPN? Sur une autre note, comment peuvent-ils vous empêcher de faire de l'espionnage d'entreprise lorsque toutes les ressources sont disponibles à l'extérieur de l'entreprise? Ce sont les arguments informatiques et de gestion contre l'externalisation de l'hébergement. Une grande entreprise doit voir les choses de cette façon. Pour une petite entreprise, vous regardez le résultat net et combien cela coûterait de mettre en place tous ces services.

C'est en fait moins cher pour une grande entreprise de le faire en interne. Ils ont déjà les ressources informatiques, ils ont juste besoin de mélanger un peu les responsabilités. Et si la solution prend largement soin d'elle-même avec seulement un entretien périodique nécessaire (sauvegardes et gestion des utilisateurs), raison de plus pour la garder à l'intérieur des portes de l'entreprise.

Quant à l'hébergement Windows, c'est un problème d'organisation par organisation. Plusieurs entreprises ont avalé le koolaid Windows. D'autres ont avalé le koolaid Linux. D'autres le considèrent au cas par cas. Vous devrez respecter les règles que le service informatique a définies pour votre organisation. Tant que votre solution peut être hébergée sur l'un ou l'autre, vous êtes en or.

Enfin, dans une organisation aussi grande, il est garanti que tous les fiefs veulent faire les choses à leur manière. Ils ont tous des arguments convaincants pourquoi ils ont choisi VSS, PVCS, SVN, ou quoi d'autre. Pour l'informatique, ils sont tous les mêmes. La seule façon de se consolider au sein d'une organisation aussi grande est de faire passer l'ordre par le haut. De telles commandes rencontrent toujours une résistance, et ce n'est probablement pas quelque chose que votre entreprise veut faire à moins qu'il y ait des avantages évidents de coût total de possession (TCO) à avoir un système de contrôle de version standardisé.

Je travaille également dans une entreprise financière / d'assurance (mais pas aussi grande que celle pour laquelle vous travaillez actuellement). Nous avons également plusieurs équipes de développement, et bien que l'entreprise ait choisi spécifiquement des produits Microsoft pour se développer, il n'y a toujours pas d'architecture maître, de langage ou de contrôle de source. Nous utilisons tous .Net, mais nous avons plusieurs projets dans différentes versions du framework et dans différentes langues. Certains projets utilisent VSS, d'autres TFS. Nous avons maintenant un nouvel architecte de niveau supérieur en tant que responsable QA et il a dirigé une transition plus entreprise de notre suivi des bogues de Hodge-Podge, contrôle des sources, utilisation du framework à une implémentation plus universelle de TFS pour tout cela. Ceci n'est rendu possible que par le fait qu'il est a) extrêmement expérimenté dans la nature du logiciel,

Pour résoudre ce problème au sein de votre propre organisation, vous devez d'abord considérer certaines choses:

1. Pourquoi êtes-vous si amoureux de GitHub comme réponse? Recherchez-vous un contrôle de source commun ou cherchez-vous une raison pour implémenter quelque chose avec lequel vous êtes à l'aise? Je ne connais pas la réponse (et franchement je m'en fous), mais c'est une question qui se posera lorsque vous commencerez à fouiner dans les affaires des autres.
2. Êtes-vous actuellement affilié à l'une de ces équipes logicielles? Si oui, vous devrez peut-être trouver une personne non affiliée et bien positionnée pour défendre le concept. Sinon, d'autres équipes de développement peuvent simplement penser que vous essayez d'imprimer votre réflexion sur elles. Cela les rendra encore plus résistants au concept car ils ont déjà quelque chose qui fonctionne (à leur avis).
3. Avez-vous contacté des personnes d'autres équipes pour obtenir l'adhésion au concept? D'autres développeurs ont-ils des opinions ou des préoccupations similaires? Une autre voie pour y parvenir est de se constituer une masse critique parmi les personnes qui effectuent le travail. Au fur et à mesure que de plus en plus de gens demanderont un référentiel source commun, la direction devra en tenir compte.
4. Connaissez-vous suffisamment le code / processus / exigences des autres équipes pour dire que GitHub fonctionnera (ou ne fonctionnera pas) pour eux?

Quant à votre question finale (ou réelle?), La seule vraie raison impérieuse à long terme du point de vue des chefs d'entreprise est qu'elle permet d'économiser de l'argent. Ces économies pourraient prendre la forme de temps d'arrêt réduits, d'une sécurité accrue du code, d'une productivité accrue des développeurs, d'une redondance accrue de la base de code (pour la sauvegarde), etc., et al. En fin de compte, vous devrez convaincre les personnes qui rédigent des chèques pour tout cela que le temps, les efforts et l'argent dépensés pour passer à un tel modèle en valent la peine en fin de compte comme retour sur investissement. Vous devrez également montrer que le futur soutien à ce même modèle sera là lorsque "lentement et délibérément" arrivera finalement.

Il y a beaucoup de choses qui entrent dans un tel changement d'entreprise dans la doctrine, il faudra donc beaucoup d'enthousiasme à la base et vous aurez certainement besoin de quelqu'un au niveau VP pour défendre le concept. Un gestionnaire peut travailler, mais un cadre aura beaucoup plus d'autorité pour imprimer des concepts sur d'autres groupes.

Ces entreprises voudront centraliser leurs référentiels. SVN, VSS et PVCS ont une chose en commun - ils sont tous une architecture client-serveur. Git est conçu comme VCS distribué et est par nature décentralisé.

GitHub - encore plus problématique. C'est un service externe. Le code source dans un service externe est quelque chose que la direction n'acceptera probablement jamais.

Il existe cependant une solution qui pourrait satisfaire les deux parties. Git a le git-svncommandement. Fondamentalement, vous auriez un référentiel SVN, mais certains développeurs peuvent choisir d'avoir leur propre dépôt GIT local et de le synchroniser avec le dépôt SVN centralisé. Bonne alternative aux succursales privées ou l'envoi de correctifs non engagés. Bon guide pour l'intégration de git-svn .

Plusieurs de ces réponses sont considérablement obsolètes en ce qui concerne les commentaires sur GitHub et la sécurité en raison des modifications apportées à GitHub depuis leur publication.

• GitHub ne vous oblige pas à être hébergé en externe
• La version gratuite de GitHub est ce qui met cette restriction en place.
• Il existe une version d'entreprise de GitHub disponible pour l'hébergement interne . https://enterprise.github.com/home . Ce n'est pas gratuit et coûte $ bien sûr

L'entreprise dans laquelle je travaille vient de commencer à l'utiliser et nous avions les mêmes préoccupations EXACTES car notre code est un secret commercial, nous sommes dans le secteur financier. Cela mis à part, il existe d'autres façons d'utiliser GIT qui n'impliquent pas GitHub qui sont similaires, redmine, gitosis, etc ...

Concernant la question "qui l'utilise": PayPal, Etsy, rackspace, vimeo, SAP, JPL de la NASA , noyau Linux

Les raisons techniques impérieuses sont trop nombreuses pour être énumérées. La seule chose sur laquelle il convient de se concentrer ici est les problèmes de grande taille des grandes entreprises que les autres réponses soulignent. Le plus gros problème auquel je puisse penser est la cohérence, l'uniformité, un audit clair, la simplicité de l'audit. Bien que résoudre un trésor de problèmes avec beaucoup de ces autres systèmes VCS soit un gros problème.

Il y a des réductions d'efforts dupliqués pour tous ces départements qui doivent écrire différents scripts farfelus à intégrer entre les différents systèmes, les auditer et en rendre compte et les contrôler.

• Chaque fois que j'ai dû utiliser SVN dans un environnement paranoïaque comme une société de négoce, les crochets absurdes de «conformité» et de «sécurité» étaient extrêmement nuisibles aux performances.

Depuis que j'ai passé sous silence les problèmes d'utilisation technique d'un prospect dev, je vais dire ceci. Avec plus de 15 ans d'utilisation totale, j'ai utilisé CVS, SVN, CMVC, clearcase, perforce et d'autres systèmes dans un cadre professionnel avec GIT. Si quelqu'un voulait que j'utilise autre chose que GIT (à l'exception peut-être de bzr, mercurial, perforce et clearcase (selon la configuration des deux derniers)), je saurais immédiatement que mon temps est mieux dépensé ailleurs. J'étais presque à cette conclusion (bien qu'étendant une légère allocation à CVS et SVN) en 2009. J'en avais tellement marre de la courte utilisation de SVN sur mon lieu de travail que j'ai commencé à utiliser GIT comme client SVN au début de 2010 avant nous aidant à nous convaincre de passer au GIT.