Cuantificación de las ventajas de un sistema moderno de control de versiones [cerrado]

He trabajado como líder / desarrollador de equipo en un gran entorno empresarial financiero durante la mayor parte de tres años. Nuestro proceso de lanzamiento de producción es una pesadilla porque gira en torno a Clearcase. Tenemos un grupo de administración de cambios que ejecuta todas las versiones y que solo permitirá el código en producción que se tomó de él.

Una de las primeras cosas que hice al unirme fue establecer mi equipo con Git. Todos estuvieron de acuerdo en que Clearcase era horrible y poco práctico para manejar los asuntos cotidianos de control de fuentes. Así que configuramos una especie de repositorio "no oficial" en mi máquina local y escribí un script para sincronizar nuestros repositorios git y Clearcase en el momento del lanzamiento.

La noticia de esto se extendió a otros equipos y varios han adoptado el mismo proceso. Usar git de manera "no oficial" para las actividades diarias y "oficialmente" usar Clearcase para lanzamientos. Me he convertido en el tipo de persona que tiene problemas con Git.

Así que tengo una reunión esta semana con el SVP en cambio de infraestructura que específicamente quiere que le explique los méritos de Git. Aparentemente se corrió la voz de mis frecuentes quejas en Clearcase. Si ella acepta mis argumentos, tendré una oportunidad real de ayudar a mi empleador a deshacerse de esta abominación.

Mi experiencia con los ejecutivos me dice que a) quieren explicaciones extremadamente concisas para todo b) solo están interesados ​​en hechos que involucran cifras en dólares

Para un desarrollador, puedo explicar los méritos de Git sobre Clearcase (o CUALQUIER otro sistema de control de versiones sobre Clearcase), pero estoy dejando en blanco cómo hacer esto a un ejecutivo técnico sin antecedentes técnicos (ella tiene un MBA e hizo su licenciatura en geografía).

Siento que cualquier argumento que le haga va a sonar como una tontería técnica o que estoy evangelizando mis preferencias personales.

Lo que estoy tratando de encontrar son hechos concretos que demuestran que los desarrolladores trabajan de manera más efectiva con Git o CUALQUIER sistema de control de fuente moderno.

Creo que el hecho de que los otros equipos hayan comenzado a usar Git internamente es una señal significativa, pero aún no es lo suficientemente fuerte porque todavía se puede descartar como preferencia personal.

Lo que realmente necesito es algo lo suficientemente poderoso como para romper el "Este proceso ha funcionado durante 20 años, ¿por qué deberíamos cambiarlo?" argumento.

He estado en situaciones muy similares (en las industrias aeroespacial y automotriz). No espere progresar mucho en esta o en las reuniones posteriores. Ambas situaciones superaron mi deseo de seguir luchando por mejorar, pero esta es la mejor táctica que he visto hasta ahora ...

Usted dice "este proceso ha funcionado durante 20 años", pero ¿realmente? Comience describiendo lo que quiere decir con "nuestro proceso de lanzamiento de producción es una pesadilla". Cree una lista de problemas con el proceso / herramienta actual que sea lo más independiente posible de ClearCase.

Luego, cree una lista de "soluciones" de proceso / herramienta que sean lo más agnósticas posible de Git (aunque Git o cualquier DVCS moderno desearán ajustarse exactamente a la factura). Explicar por qué Git es mejor que ClearCase no significa nada para los no usuarios.

Permita que el equipo de infraestructura confirme que el enfoque actual tiene los problemas que identifica. Esto probablemente los llevará a buscar soporte de IBM para "solucionar" estos problemas. Permanezca conectado para garantizar que IBM no deje de lado los problemas. Debido a que ClearCase carece de las propiedades básicas de nuestra comprensión moderna del control de versiones, la mayoría de estos problemas no se pueden solucionar o requerirán un cambio importante en la infraestructura.

Con suerte, en este punto, el equipo de infraestructura verá esto como un problema comercial, pero sin una solución fácil. En este punto, ofrece comparar soluciones adicionales con costos estimados. Dado que muchos de sus equipos ya están usando Git, debería poder eliminar la capacitación como gasto.

¡Buena suerte!

Nuestro proceso de lanzamiento de producción es una pesadilla porque gira en torno a Clearcase. Tenemos un grupo de administración de cambios que ejecuta todas las versiones y que solo permitirá el código en producción que se tomó de él.

No, su proceso es una "pesadilla" debido a su grupo de administración de cambios y sus procedimientos de lanzamiento. Continúe y reemplace Clearcase por SVN o git o Fossil. Tendrás exactamente los mismos problemas . (Creo que lo están haciendo bien TBH, los controles de liberación fuertes son esenciales).

Esto es en lo que debe enfocarse, no en las credenciales geek de git (que son irrelevantes para todos excepto para los desarrolladores), debe enfocarse en el caso comercial para cambiar el proceso para que sea menos oneroso. Lo más probable es que puedas hacerlo usando Clearcase, pero te da la oportunidad de esconder la idea de usar git de todos modos.

Si no mira la "imagen más grande" aquí, el mejor de los casos será que use git con las mismas restricciones que requiere el grupo de lanzamiento. SI considera los aspectos más amplios de para qué sirve el control de cambios, apreciará las restricciones que tendrá que implementar para que git sea útil en el tipo de proceso de lanzamiento fuertemente controlado que su organización necesita.

Algunas ideas para usted: haga que vean los problemas de productividad con el sistema actual desde el punto de vista del desarrollador. Haga esto como parte 1 de 2. Parte 2, vaya y trabaje con ellos en una versión para que pueda ver los problemas de control que los desarrolladores deben comprender. Trátelo como un ejercicio de aprendizaje para que ambas partes vean la vista de la otra parte, y luego debería ser capaz de encontrar una solución que aún resuelva los requisitos principales que cada parte tiene. Tenga en cuenta que los lanzamientos son más importantes que los desarrolladores, por lo que debe estar preparado para dar más de lo que espera.

Una vez que tenga conocimiento de lo que se requiere para los lanzamientos, debe aceptar redactar un documento de proceso detallado (con los detalles a seguir) que puede mostrarles dándoles lo que necesitan. Depende de usted cómo puede masajear esto para que el lado del desarrollador sea mejor para usted. Me imagino que realmente no les importa cómo dev hace dev, siempre que la fuente se administre correctamente y los lanzamientos se organicen correctamente, eso significa que tendrá que mostrar cómo los cambios de código pueden vincularse para cambiar tickets, cómo tomar el código que hizo un lanzamiento para parchar, construir y volver a lanzarlo.

Los ejemplos específicos impresionarán más que las ventajas abstractas. Creo que tendrá más éxito si puede documentar ejemplos particulares donde (a) Clearcase causó problemas que tomaron tiempo en resolver y (b) Git resuelve esos problemas. Recuerde que no necesita entrar en detalles técnicos de por qué esto es así (a menos que se le solicite) simplemente demuestre que es así; la gerencia no necesita conocer los tecnicismos, eso es lo que le pagan.

Si puede adjuntar escalas de tiempo y fechas específicas a estos ejemplos, mucho mejor. También puede completar esto mostrando que la tarea X que hace mucho toma Y minutos en Clearcase y Z minutos en Git.

Recuerda que el tiempo es dinero, así que si puedes demostrar que trabajar con Git es más rápido , puedes demostrar que también tendrá sentido financiero.

Aquí hay un intento de cómo lo intentaría.

Eso puede sonar estúpido para un desarrollador, pero para la administración, los cambios tecnológicos se consideran riesgosos.

"Si la cosa mágica ya funciona, ¿por qué arriesgarse a romperla?"

Por lo tanto, tienes que voltear la mesa. Haga que sea más arriesgado no hacer el cambio a git. A toda costa, no lo hagas sonar como si fuera un juguete nuevo.

Comenzaría diciendo que git ahora se usa ampliamente. Use números, como esos: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Para un administrador, esto implica que deberían poder encontrar muchos desarrolladores usando git. Y todo un ecosistema de herramientas de terceros (escuché que incluso Microsoft integra git con Visual Studio ahora).

Además, no se puede culpar a un gerente por seguir las cosas convencionales, ¿verdad? En contraste, ¿quién usa $ other_cvs aquí?

Ponga énfasis en cómo los proyectos grandes lo están usando, porque es simple, rápido, flexible, poderoso ... Encuentre grandes proyectos con grandes nombres (GNU / Linux, Google, Microsoft ...) que usan git.

Después de haber demostrado que no puede ser un mal movimiento, podría continuar para mejorar las cosas en su caso.

Desea que la empresa siga siendo competitiva y no sea superada por equipos más rápidos y ágiles, ¿verdad? Trataría de encontrar algunas estimaciones internas (escritas) sobre cómo cambió la productividad usando Clearcase vs Git. Podrías usar algo de ayuda de tus compañeros desarrolladores allí. Luego extrapolar para toda la empresa (es decir, todos los desarrolladores de software), con números y costo estimado de permanecer con Clearcase.

Incluso si fuera apropiado, recapitule todo en un correo electrónico escrito después de la reunión (incluya a las personas adecuadas).

Lo que realmente necesito es algo lo suficientemente poderoso como para romper el "Este proceso ha funcionado durante 20 años, ¿por qué deberíamos cambiarlo?" argumento.

Este es un argumento no válido (los carruajes tirados por caballos "han funcionado durante siglos", pero probablemente desee comprar un automóvil).

He escuchado el mismo argumento sobre svn vs. mercurial (yo era el que usaba mercurial en mi sistema de desarrollo).

Este problema no se trata de reemplazar lo que funciona; No intente expresarlo como tal, y si esta es la pregunta que necesita "derrotar", debe comenzar señalando que no se trata de lo que funciona o no, sino de las ventajas que tiene con git , cuando ambos funcionan (y por qué git funciona mejor).

Buenos argumentos para usar git:

• git está centrado en el conjunto de cambios en lugar de centrarse en el archivo. Esto significa que los cambios son más fáciles de rastrear en todos los archivos (rastreabilidad en todo el proyecto).

• git se distribuye en lugar de centralizado; Esto significa que registrar cosas no está limitado por la velocidad de la red, lo que ahorra mucho tiempo nuevamente. También significa que no tiene un punto único de falla en caso de que su servidor ClearCase se caiga.

• debido a su sistema de ramificación, git minimiza la necesidad de combinar (es decir, no combina archivos en cada registro, sino en cada función completada). Pasas de resolver conflictos de fusión (si los hay) algunas veces al día (en cada confirmación) a una o dos veces por semana (en cada función completada). Esto significa más tiempo de desarrollo para sus desarrolladores (algo que los gerentes querrán maximizar).

Creo que el hecho de que los otros equipos hayan comenzado a usar Git internamente es una señal significativa, pero aún no es lo suficientemente fuerte porque todavía se puede descartar como preferencia personal.

Puede señalar que la diferencia cualitativa es tan grande que los desarrolladores de su empresa prefieren las complicaciones de instalar, configurar y usar git, además de Clearcase, por sus características adicionales. En realidad, es un argumento fuerte (si no proporcionara una experiencia de usuario y un conjunto de características completamente mejores, las personas no harían un esfuerzo adicional para usarlo, especialmente porque es algo que no que la empresa requiere).

Así que tengo una reunión esta semana con el SVP en cambio de infraestructura que específicamente quiere que le explique los méritos de Git.

Dibuje un cuadro que represente las confirmaciones con los dos sistemas y muestre la racionalización obtenida por los desarrolladores que no se comprometen públicamente (es decir, si compila un archivo, el resto del equipo no está bloqueado e incapaz de cumplir hasta que lo arregle). También explique los controles de calidad adicionales que puede realizar cuando puede realizar confirmaciones intermedias sin afectar a nadie más, el hecho de que puede obtener diferencias claras por función (esencial para las revisiones de código).

Lo que realmente necesito es algo lo suficientemente poderoso como para romper el "Este proceso ha funcionado durante 20 años, ¿por qué deberíamos cambiarlo?" argumento.

Es difícil juzgar realmente cuál sería un buen argumento sin ser testigo de la escena. Pero intentaré ayudarte a enmarcar tus argumentos para que puedan ser escuchados.

Supongo que su audiencia debe tener un nivel de conocimiento no experto en el tema y tener interés en mantener el curso actual. Tienen diferentes preocupaciones y responsabilidades, y pueden sufrir serias consecuencias si algo sale mal, por lo que tendrá que trabajar desde esa mentalidad. Anticipe algunas de las preguntas o preocupaciones que puedan tener:

• ¿Qué nuevas capacidades traería esto? ¿Hay algo que actualmente no podamos hacer, que nos gustaría hacer y que esta nueva cosa nos permita? Comience con una nota positiva.

• ¿Cuál es el impacto en los cronogramas de lanzamiento? ¿Cuál es el costo de implementar este cambio hacia la próxima versión inmediata? ¿Cuáles son los costos y beneficios de las siguientes versiones?

• ¿Esto implicará un cambio en el proceso? A diferencia del calendario de lanzamiento, ¿este cambio requerirá que las personas en el proceso de lanzamiento cambien sus formas? ¿Será esto transparente para ellos o necesitarán adaptarse? ¿Necesitará cooperar con otros departamentos? Las personas son resistentes al cambio.

• ¿Existen peligros inminentes al apegarse al sistema actual? ¿El proceso actual tiene dependencias de software o hardware que han desaparecido o terminarán pronto? ¿Se basa en el conocimiento especializado de las personas que aumenta los costos de contratación? ¿Tiene un agujero de seguridad potencial que el nuevo sistema conecta (puntos de bonificación si este agujero puede conducir a acciones legales)? No agite con la mano o 'tal vez' o 'probablemente' esto: la sensación es que funcionó bien durante 20 años, por lo que la carga de la prueba recae en el defensor del cambio.

Además, sea ​​específico sobre los problemas y las soluciones. . Si no puede encontrar ejemplos específicos, use estimaciones honestas de su posición como experto. Los ejemplos de otras empresas / departamentos / entidades que adopten dicho cambio, preferiblemente de su industria, y su evaluación de ese cambio, lo ayudarán. (No elija ejemplos que hayan tenido algún tipo de problema publicitario de TI en los últimos años, o le corresponderá a usted demostrar que este cambio no fue la causa).

¿Puede encontrar esta respuesta para convencer a la empresa para la que trabajo de implementar el control de versiones? servicial.