Razones contra el uso de "Git" en la empresa

Recientemente utilicé un sistema comercial de control de versiones controlado centralmente en una gran compañía con aproximadamente 100 subsistemas diferentes escritos en diferentes sistemas operativos e idiomas, y he notado que varios desarrolladores usan git o mercurial en sus proyectos favoritos, pero no para su trabajo sistemas. Personalmente, estoy más familiarizado con git, pero me preguntaba qué razones tienen para "No" usar Git en la empresa, aparte del hecho de que la elección ya se ha realizado (tenemos muchos problemas con nuestro sistema de versión controlado centralmente, así que puedo No digo que sea shiny).

Actualizar

El mundo realmente ha cambiado desde que escribí esto. La compañía en cuestión que en realidad desautorizó a Git en el momento ahora usa Mercurial como su sistema preferido

Tengo que estar en desacuerdo con las ideas que las empresas temen libres o que tardan en cambiar. Esto puede ser cierto, pero usarlos para descartar la lenta tasa de adopción de git en el espacio de Enterprise no tiene ni idea de lo que significa Enterprise. Además, SVN es bastante popular y es gratis.

Enterprise se trata de centralización. Desea que todos sus desarrolladores sigan el mismo procedimiento, obtengan el mismo código, etc.

Eric Sink es más eloquent sobre este tema de lo que podría ser: http://www.ericsink.com/articles/vcs_trends.html

Si tuviera que adivinar, diría que es porque la empresa siempre ha sido cautelosa al usar cosas "gratis". Principalmente porque carecen de un sistema de soporte estable (generalmente, el soporte viene en forma de StackOverflow.com o foros cuando se trata de código abierto), pero también hay una mentalidad dominante de "obtienes lo que pagas". Se dan count de que si no les cuesta una carga en las tarifas de licencia, debe valer tanto en términos de usabilidad real.

Por supuesto, nosotros, como expertos en tecnología, sabemos que eso es una carga.

En mi experiencia, las empresas tienen muchos antitesis contra el cambio

  1. Conjuntos de habilidades existentes : si una gran parte del equipo tiene habilidades en las herramientas existentes, se convertirán automáticamente en un obstáculo para cambiarlas, incluso para las mejores.
  2. Estabilidad consolidada : el cambio siempre es un dolor en términos de migration y estabilidad. Lo que está en producción "funciona por naturaleza" y cada cambio siempre crea problemas.
  3. Cumplimiento : las herramientas existentes han sido analizadas y validadas por Enterprise ICT Security y luego definidas como "estándar y conforme" con los procedimientos de la compañía. Cualquier cosa diferente se verá como un posible riesgo de security.

En mi humilde opinión, el problema no es el propio GIT ni el Control de versiones distribuidas: el problema es cambiar el SCM y dirigirse hacia algo desconocido y potencialmente "peligroso" para el set de reglas de Enterprise. Es por eso que los "anticuerpos" entran en juego para evitar cualquier cambio significativo.

Más específicamente en GIT, muchos riesgos y amenazas están proporcionando arguments adicionales contra su adopción, relacionados con los tres puntos mencionados anteriormente:

  1. Conjunto de habilidades: GIT es diferente de cualquier otro SCM utilizado hasta ahora. Nombrar es ambiguo y engañoso (el "svn checkout" es un "clon git" … mientras que un "git commit" no es un "svn commit")
  2. Estabilidad consolidada: GIT ha sido muy inestable hasta Ver. 1.6. Lo hemos usado en Windows desde Ver. 1.5 y ha sido un verdadero dolor, particularmente con desarrolladores inexpertos.
  3. Cumplimiento: GIT no tiene aplicación de identidad por defecto y no proporciona un rastro claro de quién hizo qué. Es "peer-to-peer", por lo que por naturaleza está en contra del control central y la auditoría.

He visto los "anticuerpos" en acción muchas veces antes de GIT:

  • 1996: migration de RCS a CVS
  • 2001: migration de SourceSafe a CVS
  • 2005: migration de CVS a Subversion
  • 2009: migration de Subversion a Git

En todos esos ejemplos ha sido key destacar el más y el less del cambio en términos de toda la empresa: evaluar riesgos, costos y beneficios … y todo con claridad en mente quiénes son los anticuerpos y cómo podemos mitigarlos. o "asegurarles un buen callejón para que caminen con herramientas viejas".

Después de mucho dolor y esfuerzo, ¡ todas esas migraciones finalmente tuvieron mucho éxito! He presentado GIT en grandes empresas como Vodafone Group Services en el Reino Unido y Alemania . Después del dolor y la resistencia de todos modos, el cambio ha despegado y los beneficios son visibles y ya han proporcionado un ROI significativo en términos de eficiencia, agilidad y control .

Desde el punto de vista del cumplimiento y el apoyo, he visto ayudar positivamente a la adopción del patrocinio asistido por el vendedor. Algunos ejemplos:


En términos generales, el cambio es la tarea más costosa pero MÁS IMPORTANTE en una empresa grande , ante todo desde el punto de vista de la mentalidad de las personas.

Déjame saber lo que piensas acerca de las adopciones de Git y Enterprise Tools.

Luca / @lucamilanesio

Algunas de las muchas razones:

  • Inercia: hay una gran cantidad de personas que conocen los sistemas centralizados. No tiene que "capacitar" a los desarrolladores si simplemente no cambia.

  • Interacciones con otras herramientas: los entornos corporativos son, por supuesto, grandes en herramientas adicionales como continuous integration, IDE, rastreadores de problemas de lujo, etc. Naturalmente, hay más apoyo para los VCS centralizados establecidos con los que con los relativamente nuevos git y hg.

  • Soporte: Cuando compra un producto VCS comercial, no solo está comprando el progtwig, sino que está comprando tranquilidad.

Por supuesto, no estoy diciendo que estas sean buenas razones; solo están convenciendo a las personas en position de tomar esta decisión. Creo que vale la pena superar la inercia: requiere trabajo ahora, pero vale la pena más tarde. Creo que las herramientas externas están mejorando en el soporte de git, particularmente las de código abierto, solo necesitan complementos. Y en cuanto al soporte, todos sabemos que hay mucho apoyo less formal en Internet.

Realmente, hay un pensamiento común en todos estos: la filosofía del software libre simplemente no es la forma en que las empresas hacen negocios. Comprar un producto está establecido y es fácil. Usted paga su dinero, obtiene lo que necesita. La administración no tiene que preocuparse. Usar un producto de software libre … bueno, puede ser mucho mejor, pero es más complejo de manejar. No viene en una caja.

Una aclaración: uso la palabra "libre" de la misma manera que lo hacen los que están en el mundo del software libre, libre como en libertad, no como en la cerveza. Con suerte, esta frase se perforará en la cabeza de todos con el time. Tenga en count que nunca abordé el tema del costo aquí, aunque sí creo que en el caso de git, en general será más barato que una solución comprada a pesar de los costos de poner a todos al stream y asegurarse de que encaja con el rest de su process. Sin embargo, este no es un tema de corte y, como creo que git sale adelante, no tiene sentido ponerlo entre las balas.

Desde mi experiencia, es el miedo al cambio. La administración del código fuente es una pieza central de la infraestructura y afecta a todos los desarrolladores. Si el sistema actual no duele demasiado, la TI realmente luchará contra el cambio.

Otra razón que he escuchado bastante a menudo es que la integración de IDE aún no ha alcanzado la calidad de, por ejemplo, CVS o Subversion. Aunque el argumento es cierto, se está convirtiendo cada vez más en un problema.

Se puede hacer la misma pregunta sobre cambiar cualquier service de infraestructura grande por otra cosa. Cuando hay cientos o miles de personas que usan algo, es mejor que se rompa o que lo nuevo ofrezca algunas características atractivas.

Piensa en cambiar los sistemas de correo electrónico. Alguien tendrá que capacitar a todos los usuarios, transferir todos los posts, realizar el cambio con un time de inactividad mínimo y sin perder datos, y luego convencer a la gerencia de que no va a causar una interrupción importante en las operaciones comerciales.

En su ejemplo específico, la conversión del sistema de control de origen para 100 subsistemas conservando el historial y el reciclaje de todos los desarrolladores, probadores e ingenieros de lanzamiento, y sin afectar su productividad diaria, es una tarea enorme. El sistema existente tendrá que ser realmente roto.

Git es un sistema de control de versiones con una actitud de queueboración y de intercambio. Prácticamente no hay forma de que pueda aplicar un patrón específico de acceso y uso compartido. Si las personas que usan git no quieren seguir sus reglas, la herramienta no ayudará mucho.

Aunque personalmente creo que este tipo de comportamiento organizacional es estúpido, estoy seguro de que en algún lugar alguien piensa que es una buena idea. Tal vez le preocupa que sus empleados ingobernables trabajen en los proyectos incorrectos, o está desesperado por evitar cambios en el código.

"Además del hecho de que la elección ya se ha realizado"

Esa parte de la statement es realmente demasiado importante como para ignorarla, porque se relaciona con la curva de aprendizaje de cualquier herramienta en particular. Aprender, por ejemplo, SVN lleva un time, y el process de aprendizaje cuesta dinero en forma de time de desarrollador. Aprender git, en mi experiencia, lleva más time y se vuelve más complejo en ausencia de interfaces simplificadas (a pesar de que el desarrollo continuo de gittortoise). Además, Git tiene tantas herramientas que su curva de aprendizaje podría considerarse una pendiente de aprendizaje.

El pago después de superar la curva es excelente, pero el requisito inicial es una barrera para la adopción.

Una barrera práctica importante para la adopción de la empresa, además de la falta de control e integración central como lo menciona Eric, es la "facilidad de uso".

Si está acostumbrado a Subversion, o herramientas similares como PVCS, entonces Git (y DVCS en general) representa una colina de aprendizaje significativa para escalar, tanto en el nivel conceptual como en el flujo de trabajo diario. En mi experiencia (algo hastiada), muchos desarrolladores empresariales a menudo no están dispuestos a invertir el esfuerzo en aprender una nueva herramienta o conceptos; y me temo que echarán a perder cualquier bash de introducir DVCS.

Por favor pruébame mal

Aquí hay algunas recomendaciones específicas. (lea el blog completo aquí ).

Si tiene requisitos convincentes para una única copy maestra de su trabajo, use Subversion. Puedes hacer esto con Git, siempre y cuando no haya deslices. Pero no puedes hacer nada más con Subversion (slip-ups o no), y los "requisitos convincentes" como Sarbanes-Oxley son más felices con las garantías que con las posibilidades.

Si planea mantener líneas paralelas, en gran medida compartidas pero permanentemente diferentes del mismo producto, use Git. Un ejemplo común: quizás tenga un producto grande que personalice para cada cliente. Las personalizaciones son permanentes, y generalmente no se comparten entre líneas de código, pero la mayoría del código es común a todos. Git fue diseñado solo para este caso (en términos de Git, personalizaciones locales para el núcleo común, y funciones ocasionales o contribuciones de errores en el tree de respaldo).

Ninguno de esos? Haga su elección, debería estar bien con cualquiera de las herramientas.

Parte de la dificultad no se debe al sistema sino a la organización de los trabajadores.

SVN es fácil de entender y usar, pero es mejor si se usa para pocos dev trabajando en una sola twig (o cabeza)

Git es una buena idea, pero la implementación es muy desagradable y requiere MUCHA cantidad de time y trabajo para hacer algo tan simple como poner tu maldito código.

aún esperamos un DVCS DECENTE …