¿Por qué las grandes compañías financieras / de seguros deberían usar git y / o github?

Trabajo para una gran empresa (30K empleados) en la industria financiera / de seguros. Si bien "TI" no es nuestro enfoque principal, seamos honestos, estas son industrias impulsadas por la información y las empresas con la mejor ventaja tecnológica parecen avanzar más rápido.

Hay muchos equipos de desarrollo de software en mi empresa. Están en todo el mapa con control de versiones, y mucho menos los idiomas / marcos utilizados. Algunos no usan ninguno (lo sé), algunos usan PVCS, algunos usan VSS y los más ilustrados usan SVN.

Quiero traer git a mi empresa. Más específicamente, quiero traer GitHub (repositorios privados). Conozco a las personas adecuadas para hablar sobre esto, pero seamos honestos nuevamente, los movimientos drásticos como este generalmente son derribados en el entorno de las grandes empresas debido a preocupaciones vagas de seguridad o al hecho de que ninguno de nuestros competidores lo está utilizando (y puedo solo cite jQuery, Ruby on Rails, Facebook, etc. como referencias).

Así que mi pregunta es esta. ¿Cuáles son las razones más convincentes de por qué una gran empresa debería cambiar lenta y deliberadamente de PVCS / VSS / SVN a una solución git alojada como GitHub (repositorio privado)? Por supuesto, parte de mi plan involucra un POC para un proyecto de desarrollo no esencial.

Hay algunas cosas que podrían preocuparme, como un tercero desinteresado. Así que permítanme arrojarles algunas preguntas que es mejor que estén preparados para responder (a su departamento de TI):

• Cualquier control de versión es mejor que ninguno. Tenemos mucho para elegir, ¿qué hay de malo en eso?
• Control de versiones distribuido? ¿Que es eso? ¿Cómo controlamos eso?
• ¿Cuanto cuesta? No solo el software, sino también los servidores, licencias, mantenimiento, etc.
• No confío en GitHub, ni en ningún alojamiento externo. Necesitamos hacer todo en casa. ¿Por qué no podemos configurar nuestro propio servidor?
• ¿Podemos ejecutarlo en Windows? Tenemos que mantenerlo en nuestra línea base actual, ya sabes.
• ¿Cómo aseguramos la cosa? SVN tenemos, pero esto me da miedo.

Estas son las primeras preguntas que surgirán. En cuanto a VSS y PVCS, es probable que pueda encontrar un montón de argumentos razonablemente buenos (como el historial de versiones corrupto de VSS). SVN será un poco más difícil. Recomiendo encarecidamente centrarse en las capacidades de fusión de GIT, y también recomiendo mantener una mente abierta sobre Mercurial. Cada argumento para GIT también es un argumento para Mercurial, y Mercurial tiene un soporte de Windows más maduro.

La seguridad es de suma importancia para las instituciones financieras y gubernamentales. Serán extremadamente resistentes a los recursos alojados externamente. Desde una perspectiva de gestión de riesgos, considere lo que podría suceder si alguien piratea GitHub y roba el código fuente, o descubre la vulnerabilidad de seguridad documentada en el rastreador de problemas. Eso sería devastador para la empresa. Desde una perspectiva de gestión pura, si la empresa es legalmenterequerido para pagarle por cada hora que trabaja, ¿cómo pueden monitorear si está trabajando desde su casa cuando los recursos están fuera de su red VPN? En otra nota, ¿cómo pueden evitar que usted realice algún espionaje corporativo cuando todos los recursos están disponibles desde fuera de la empresa? Estos son los argumentos de TI y gestión contra la externalización del alojamiento. Una gran empresa tiene que ver las cosas de esta manera. Para una empresa pequeña, observa el resultado final y cuánto costaría establecer todos esos servicios.

En realidad, es más barato para la gran empresa hacerlo en casa. Ya tienen los recursos de TI, solo necesitan barajar un poco las responsabilidades. Y si la solución se cuida en gran medida con solo mantenimiento periódico necesario (copias de seguridad y administración de usuarios), una razón más para mantenerla dentro de las puertas corporativas.

En cuanto al alojamiento de Windows, ese es un problema de organización por organización. Varias compañías se han tragado el koolaid de Windows. Otros se han tragado el koolaid de Linux. Otros lo consideran caso por caso. Tendrá que seguir las reglas que el departamento de TI ha establecido para su organización. Siempre y cuando su solución pueda ser alojada, usted es dorado.

Finalmente, en una organización tan grande se garantiza que habrá feudos que quieran hacer las cosas a su manera. Todos tienen argumentos convincentes de por qué eligieron VSS, PVCS, SVN o qué tienen. Para TI son todos iguales. La única forma de consolidarse dentro de una organización tan grande es hacer que el pedido llegue por fiat desde arriba. Dichas órdenes siempre se encuentran con resistencia, y probablemente no sea algo que su empresa quiera hacer a menos que existan beneficios obvios de costo total de propiedad (TCO) al tener un sistema de control de versiones estandarizado.

También trabajo en una empresa financiera / de seguros (aunque no tan grande como para la que estás trabajando actualmente). También contamos con múltiples equipos de desarrollo, y si bien la empresa ha elegido específicamente productos de Microsoft para desarrollar, todavía no hay arquitectura maestra, lenguaje o control de fuente. Todos estamos usando .Net, pero tenemos múltiples proyectos en diferentes versiones del marco y en diferentes idiomas. Algunos proyectos usan VSS, otros TFS. Ahora tenemos un nuevo arquitecto de nivel superior como administrador de control de calidad y él ha encabezado una transición más empresarial de nuestro seguimiento de errores de Hodge-Podge, control de origen, uso del marco a una implementación más universal de TFS para todo. Esto solo es posible por el hecho de que es a) extremadamente experimentado en la naturaleza del software,

Al abordar esto dentro de su propia organización, primero debe considerar algunas cosas:

1. ¿Por qué estás tan enamorado de GitHub como respuesta? ¿Está buscando un control de fuente común o está buscando una razón para implementar algo con lo que se sienta cómodo? No sé la respuesta (y francamente no me importa), pero esta es una pregunta que surgirá cuando comiences a husmear en los negocios de otras personas.
2. ¿Actualmente está afiliado a uno de estos equipos de software? En caso afirmativo, es posible que necesite encontrar un individuo no afiliado y bien posicionado para defender el concepto. De lo contrario, otros equipos de desarrollo pueden sentir que está intentando imprimir su pensamiento sobre ellos. Esto los hará aún más resistentes al concepto ya que ya tienen algo que funciona (en su opinión).
3. ¿Has hecho algún contacto con personas de otros equipos para ganar aceptación del concepto? ¿Hay otros desarrolladores que tengan opiniones o inquietudes similares? Otra vía para lograrlo es construir una masa crítica entre las personas que realizan el trabajo. A medida que más personas comiencen a exigir un repositorio fuente común, la administración tendrá que tomar nota.
4. ¿Está lo suficientemente familiarizado con el código / procesos / requisitos de los otros equipos como para decir que GitHub (o no) trabajará para ellos?

En cuanto a su pregunta final (¿o real?), La única razón convincente a largo plazo desde la perspectiva de los gerentes de negocios es que ahorra dinero. Estos ahorros podrían ser en forma de tiempo de inactividad reducido, mayor seguridad de código, mayor productividad del desarrollador, mayor redundancia de base de código (para copia de seguridad), etc., et al. Lo que finalmente tendrá que hacer es convencer a las personas que emiten cheques de todo esto de que el tiempo, el esfuerzo y el dinero gastado en la transición a dicho modelo valdrán la pena al final como un retorno de su inversión. También deberá demostrar que el soporte futuro para ese mismo modelo estará allí cuando finalmente suceda "lenta y deliberadamente".

Hay muchas cosas que intervienen en este cambio de doctrina empresarial, por lo que requerirá mucho entusiasmo de estilo de base y definitivamente necesitará a alguien a nivel de VP para defender el concepto. Un gerente puede funcionar, pero un ejecutivo tendrá mucha más autoridad para imprimir conceptos en otros grupos.

Dichas compañías querrán tener sus repositorios centralizados. SVN, VSS y PVCS tienen una cosa en común: son todas arquitectura de cliente-servidor. Git está diseñado como VCS distribuido y, por naturaleza, está descentralizado.

GitHub: aún más problemático. Es un servicio externo. El código fuente en el servicio externo es algo que la administración probablemente nunca acepte.

Sin embargo, existe una solución que podría mantener a ambas partes satisfechas. Git tiene el git-svnmando. Básicamente, tendría un repositorio SVN, pero algunos desarrolladores pueden optar por tener su propio repositorio GIT local y sincronizarlo con el repositorio SVN centralizado. Buena alternativa a sucursales privadas o envío de parches no comprometidos. Buen tutorial para la integración de git-svn .

Varias de estas respuestas están significativamente desactualizadas con respecto a los comentarios sobre GitHub y la seguridad debido a los cambios en GitHub desde que se publicaron.

• GitHub no te obliga a ser alojado externamente
• La versión GRATUITA de GitHub es lo que establece esta restricción.
• Hay una versión empresarial de GitHub disponible para alojamiento interno . https://enterprise.github.com/home . No es gratis y cuesta $ por supuesto

La compañía en la que trabajo acaba de comenzar a usarlo y teníamos las mismas preocupaciones EXACTAS porque nuestro código es un secreto comercial, estamos en el sector financiero. Aparte de eso, hay otras formas de usar GIT que no involucran GitHub que son similares, redmine, gitosis, etc.

Con respecto a la pregunta "quién lo está usando": PayPal, Etsy, rackspace, vimeo, SAP, JPL de la NASA , Kernel de Linux

Motivos técnicos convincentes son demasiados para enumerarlos. Lo único en lo que vale la pena centrarse aquí es en los problemas empresariales más grandes de alto nivel que señalan las otras respuestas. El más grande que se me ocurre es la consistencia, la uniformidad, la auditoría clara, la simplicidad de la auditoría. Aunque resolver un tesoro de problemas con muchos de estos otros sistemas VCS es muy importante.

Hay reducciones en el esfuerzo duplicado para todos los departamentos que tienen que escribir diferentes guiones extravagantes para integrarse entre los diferentes sistemas, auditarlos e informar sobre ellos y controlarlos.

• Cada vez que he tenido que usar SVN en un entorno paranoico como una empresa comercial, los absurdos ganchos de "cumplimiento" y "seguridad" eran muy perjudiciales para el rendimiento.

Dado que pasé por alto los problemas de uso técnico de un posible desarrollador, diré esto. Con más de 15 años de uso total, he usado CVS, SVN, CMVC, clearcase, performance y otros sistemas en un entorno profesional junto con GIT. Si alguien quisiera que yo usara algo diferente a GIT (con la excepción quizás de bzr, mercurial, forcence y clearcase (dependiendo de la configuración de los dos últimos)) , inmediatamente sabría que mi tiempo se gasta mejor en otro lugar. Estaba casi en esa conclusión (aunque extendí un ligero subsidio a CVS y SVN) en 2009. Estaba tan harto de las pequeñas caídas de cómo se usaba SVN en mi lugar de trabajo que comencé a usar GIT como mi cliente SVN a principios de 2010 antes ayudando a convencernos de cambiar a GIT.