¿Cómo puedo convencer a los programadores de vaqueros para que usen el control de fuente?

ACTUALIZACIÓN
Trabajo en un pequeño equipo de desarrolladores, 4 chicos. Todos han usado el control de fuente. La mayoría de ellos no pueden soportar el control de la fuente y en su lugar eligen no usarlo. Creo firmemente que el control de la fuente es una parte necesaria del desarrollo profesional. Varios problemas hacen que sea muy difícil convencerlos de que usen el control de fuente:

• El equipo no está acostumbrado a usar TFS . He tenido 2 sesiones de entrenamiento, pero solo se me asignó 1 hora, lo que es insuficiente.
• Los miembros del equipo modifican directamente el código en el servidor. Esto mantiene el código fuera de sincronización. Requerir una comparación solo para asegurarse de que está trabajando con el último código. Y surgen problemas complejos de fusión
• Las estimaciones de tiempo ofrecidas por los desarrolladores excluyen el tiempo requerido para solucionar cualquiera de estos problemas. Entonces, si digo no, tomará 10 veces más ... Tengo que explicar constantemente estos problemas y arriesgarme porque ahora la gerencia puede percibirme como "lento".
• Los archivos físicos en el servidor difieren de manera desconocida en más de ~ 100 archivos. La fusión requiere el conocimiento del proyecto en cuestión y, por lo tanto, la cooperación del desarrollador que no puedo obtener.
• Otros proyectos no están sincronizados. Los desarrolladores continúan desconfiando del control de origen y, por lo tanto, agravan el problema al no utilizar el control de origen.
• Los desarrolladores argumentan que usar el control de fuente es un desperdicio porque la fusión es propensa a errores y difícil. Este es un punto difícil de argumentar, porque cuando el control de la fuente está siendo mal utilizado y el control de la fuente se omite continuamente, es propenso a errores. Por lo tanto, la evidencia "habla por sí misma" en su opinión.
• Los desarrolladores argumentan que modificar directamente el código del servidor, sin pasar por TFS, ahorra tiempo. Esto también es difícil de discutir. Debido a que la fusión requerida para sincronizar el código para comenzar es lenta. Multiplique esto por los más de 10 proyectos que gestionamos.
• Los archivos permanentes a menudo se almacenan en el mismo directorio que el proyecto web. Por lo tanto, la publicación (publicación completa) borra estos archivos que no están bajo el control de la fuente. Esto también genera desconfianza para el control de la fuente. Porque "publicar rompe el proyecto". Arreglar esto (sacar archivos almacenados de las subcarpetas de la solución) lleva mucho tiempo y depuración ya que estas ubicaciones no están configuradas en web.config y a menudo existen en múltiples puntos de código.

Entonces, la cultura persiste. Las malas prácticas engendran más malas prácticas. Las malas soluciones impulsan nuevos hacks para "solucionar" problemas mucho más profundos y que consumen mucho más tiempo. Servidores, el espacio en el disco duro es extremadamente difícil de encontrar. Sin embargo, las expectativas de los usuarios están aumentando.

¿Qué se puede hacer en esta situación?

No es un problema de capacitación, es un problema de factores humanos. No quieren, y están creando bloqueos de carreteras. Trate con las dinámicas grupales rotas, cuál es la causa raíz de su objeción, generalmente el miedo, ¿es solo miedo al cambio o es más siniestro?

Ningún desarrollador profesional de hoy, o durante los últimos 20 años, se ha resistido al control de la fuente. Una vez, hace unos 30 o 40 años, cuando las computadoras eran lentas, el control de la fuente aún más lento y los programas consistían en un archivo de 500 líneas, era una molestia y había razones válidas para no usarlo. Estas objeciones solo pueden provenir del peor tipo de vaqueros que se me ocurra.

¿El sistema se ve obligado a hacerles la vida difícil de alguna manera? Descubra qué es y cambie el sistema para invalidar la objeción. Repita hasta que esté listo.

Sugiero mirar GIT o Mercurial. Puede crear un repositorio en cada árbol de código fuente, ni siquiera se darán cuenta y pueden seguir hackeando como lo hacen ahora. Puede realizar un seguimiento de los cambios que han pirateado en la base del código, realizar confirmaciones, fusionarlas en otros árboles fuente, etc. Cuando ven que combina un esfuerzo de una semana en otro producto en segundos, pueden cambiar sus ideas. Cuando retrocedas uno de sus errores con un comando y salvas el culo, incluso podrían agradecerte (no cuentes con eso). En el peor de los casos, te ves bien frente al jefe y, por un extra, haz que se vean como los vaqueros que son.

La fusión requeriría no solo un gran conocimiento del proyecto

En ese caso, me temo que estás en el arroyo proverbial sin remo. Si la fusión no es una opción, tampoco lo está implementando, por lo que está diciendo que ya no puede agregar características que ya tiene en una rama (término usado libremente) a otra.

Si yo fuera tú, reconsideraría las perspectivas de mi carrera ...

A veces, los problemas del mundo real hacen que su uso no sea práctico.

Falso.

Si el equipo no está acostumbrado a usar el control de fuente, pueden surgir problemas de capacitación

Eso no tiene nada que ver con el control del código fuente y todo que ver con la capacitación. La capacitación es fácil, económica, eficiente y se realiza en cuestión de horas. No utilizar el control del código fuente es costoso, arriesgado, ineficiente y los problemas persisten para siempre .

Si un miembro del equipo modifica directamente el código en el servidor, pueden surgir varios problemas.

Ese es el tema del entrenamiento. De nuevo. Nada que ver con el control del código fuente y todo que ver con la capacitación.

Los desarrolladores continúan desconfiando del control de fuente y, por lo tanto, agravan el problema al no usar el control de fuente

Deben estar capacitados en cómo usar el control del código fuente. Reduce el costo, reduce el riesgo, simplifica las cosas y es más eficiente. Es una inversión única que paga dividendos a cada momento.

¿Qué se puede hacer en este tipo de situación?

Comience a capacitar a todos sobre cómo usar el control del código fuente.

Actualizar

Los desarrolladores argumentan que modificar directamente el control de fuente ahorra tiempo.

Como están equivocados, es importante recopilar datos para demostrar con precisión cuán incorrecto es esto.

Lamentablemente, sin embargo, la administración parece recompensar una respuesta inmediata que es costosa a largo plazo.

La única forma de superar este sistema de recompensas es

A) Identifique que el costo a largo plazo es mayor que el valor aparente a corto plazo.

B) Identifique las recompensas reales que están en su lugar que hacen que la corrupción a corto plazo (es decir, cambios directos) parezca más valiosa que el control correcto del código fuente a largo plazo. ¿Quién recibe una palmada en la cabeza por hacer algo incorrecto? ¿Qué tipo de palmaditas en la cabeza reciben? Quien lo da Para arreglar las cosas, debe nombrar las cosas que están mal y los gerentes específicos que realmente están alentando a la gente.

C) Recomendar un sistema de recompensa revisado que valore el valor a largo plazo en lugar de la respuesta rápida a corto plazo. Diferentes palmaditas en la cabeza por diferentes razones.

D) Entrenar a las personas en las recompensas que encontraste por valor a largo plazo; valor que es claramente mayor que la respuesta rápida a corto plazo.

Los desarrolladores que se niegan a usar el control de fuente / versión deberían ser despedidos, así de simple. Como ya ha señalado, los riesgos y costos inherentes de NO usarlo superan los gastos generales en los que incurre en muchos, muchos órdenes de magnitud. Cualquiera que intente argumentar en contra de esto simplemente no debería involucrarse en el desarrollo de software y me negaría rotundamente a trabajar con esas personas.

Primero resolvimos el problema, configurando un servidor de integración continua para construir nuestro control de origen en dev. En segundo lugar, bloquee el acceso a la carpeta de solo lectura, para evitar que las personas eludan el control de la fuente y modifiquen los archivos directamente.

Es un PITA en los días en que no puede reproducir el error localmente, pero aparte de eso, es mejor poder trabajar, registrarse y seguir adelante, sabiendo que el servidor de CI lo empujará automáticamente al desarrollador.

Escucho tu dolor Entré en un par de lugares de trabajo para descubrir que el 'control de fuente' era una carpeta compartida en una unidad de red. El problema generalmente no se debe a que creen que su enfoque es superior a cualquier otra cosa, simplemente funciona y nunca se les ha presentado un flujo de trabajo que integre con éxito el control de código fuente.

Con la estructura del equipo de tierra plana que ha explicado, hacer que el cambio se empuje de arriba hacia abajo puede no ser la mejor manera de abordar la situación. Un método que vale la pena probar es obtener la compra directamente de uno o dos de los otros desarrolladores para permitir que el concepto cobre impulso. Una vez que tengas otro desarrollador a bordo, será mucho más fácil distribuirlo al resto del equipo. Lentamente, presénteles el concepto, por ejemplo, comience a trabajar en un pequeño proyecto paralelo, póngalo en marcha en Git , o incluso ramifique algo alojado en GitHub .

Comience de manera simple, introduzca los conceptos de forma lenta y separada de su flujo de trabajo diario. Los humanos son excelentes para aprender cosas y adaptarse al cambio, especialmente cuando ese cambio les proporciona un beneficio directo (piense en la evolución). Sin embargo, cuando se presenta un montón de pequeños cambios a la vez, se vuelve alienante. Una vez que tengan una idea de cómo funciona el control de código fuente y las ventajas que ofrece, intente integrarlo en uno de sus proyectos internos (si comienza un nuevo proyecto, este es un mal momento para presentarlo). Deje que los otros proyectos funcionen de la manera existente si lo desea, esto será especialmente efectivo para resaltar las ventajas del control de código decente.

Si eso falla, corre.

Obviamente tiene las habilidades técnicas para identificar y solucionar su situación, sus problemas son humanos y relacionados con el proceso.

Las personas tienden a responder mucho mejor al ejemplo que a la visión, por lo que sugeriría "arreglarlo" usted mismo:

Tome una copia de la última fuente, vuelva a estructurarla para que sea amigable con el control de versiones, cree un nuevo proyecto con una estructura útil y prospectiva (averigüe cómo va a manejar las ramas, dónde coloca las dependencias de terceros, etc.). Probablemente tengas que hacer eso en tu propio tiempo.

Luego arrastre a sus compañeros de trabajo y gerencia a una habitación y muéstreles cómo se ve el desarrollo de software en el siglo XXI. Ilustra las fallas con tu sistema actual y muestra cómo se eliminan con tu nueva estructura.

También tendrá que establecerse como el Guardián de la Fuente, ya que parece ser el único a quien le importa, depende de usted obligar a las personas (con cualquier medio técnico o psicológico a su disposición) a seguir El plan. Asegúrese de que lo único que va a un cliente proviene de una máquina de construcción fuera del control de origen. Ritualmente humilla a las personas que rompen las reglas y causan estragos. Soborna con donas ... lo que sea que funcione

Si todo eso parece demasiado esfuerzo, entonces (como se ha dicho en casi cualquier otra respuesta), obtenga otro trabajo. No valen tu tiempo.

Paso 1 - ¡despide al gerente incompetente!

Si no puede realizar el paso 1, intente que el administrador limite la implementación para que solo produzca scripts tomados del control de origen. Si los desarrolladores (que no deberían tener derechos de producción en prod, vea el paso 1 si lo hacen) quieren que sus cosas se implementen, debe provenir del control de origen. Eso resolvió nuestro problema de no usar el control de código fuente bastante bien cuando lo primero que hicimos fue usarlo para la base de datos, así como para el código C #.

¿Cómo puede alguien no querer diferentes versiones de sus archivos y la capacidad de ver las diferencias? Olvídate de ramificar y cualquiera de las cosas complejas. Ni siquiera entienden lo básico. Modificar directamente un archivo de producción sin hacer el cambio más rudimentario en un entorno de prueba es una locura. He trabajado con algunas personas y afortunadamente nunca trabajamos en los mismos proyectos.

Tus compañeros de trabajo son demasiado estúpidos para ser flojos. Eso es una pérdida de tiempo. Todo lo que puede esperar es capacitar a su gerente. A la gerencia le debe gustar el control de fuente porque les gustan todas las formas de control. Los hace sentir importantes. A la mierda los otros; arreglar al líder es tu única esperanza, ya que no puedes reemplazarlo. Comience a establecer contactos con otros desarrolladores competentes e intente que se unan a su equipo cuando tenga una apertura o haga que lo contraten en su tienda.

Este es un buen ejemplo de un proyecto donde las malas prácticas se han utilizado de forma tan generalizada que resulta prácticamente imposible solucionarlo. Arreglarlo requeriría una congelación, por lo que todo se puede limpiar sin interrupción. Desafortunadamente, tales proyectos generalmente son (por razones obvias) demasiado defectuosos para congelarse durante varios meses, los errores críticos deben repararse cada dos días.

Es posible que sienta la tentación de bifurcar el proyecto para crear una versión limpia mientras la versión sucia se trata con esas correcciones de errores diarias; pero el resultado más probable es que después de varios meses, cuando finaliza la versión "limpia", nadie puede decirle qué correcciones de errores y cambios se han incorporado desde la bifurcación (porque la misma mentalidad que permite a las personas caer en tales prácticas hace que sea poco probable que mantienen registros sobre los cambios que realizan). La versión limpia está desactualizada, la versión sucia aún funciona, así que ¿qué pasa? Se descarta la versión limpia, se dice que los negativos están en lo cierto.

Aparte de lo obvio Encuentra un nuevo trabajo, creo que la respuesta es más que todo lo anterior.

Primero diríjase a la gerencia para que se unan y se trasladen y apliquen el uso del control de fuente. Luego, haga lo que debe hacerse para mantener las cosas en funcionamiento, incluso si eso significa trabajar directamente en el servidor. Comience el proceso de poner todo en control de fuente.

Otra opción es asegurarse de que lo último esté en el servidor (lo que debe hacer independientemente) e iniciar un nuevo repositorio desde el último. Perderá la historia, pero en este punto son papas pequeñas.

Por su descripción, parece que hay uno o más problemas con la situación: el equipo de desarrollo está fuera de control o se implementó una mala solución de control de fuente. De cualquier manera, le corresponde al equipo de desarrollo usar alguna solución de control de fuente: modificar directamente el código fuente en el servicio de producción solo está pidiendo que ocurran problemas.

Desde mi experiencia, el primer paso que debe realizarse de inmediato es sincronizar el control de origen con el servidor de producción. Este paso puede ser tan simple como tomar una copia del código de producción y registrarlo; es probable que el código de producto sea la base que su equipo está desarrollando. Es posible que este paso deba aumentarse mediante una fusión con el código que flota en el sistema de control de origen existente. El código debe fluir de dev a integración / QA (o ambos), y luego a etapa o etapa / producción.

Luego, la gerencia debe exigir el uso del control de fuente. En pocas palabras, si la compilación no proviene del sistema de control de código fuente, el código no debería implementarse en producción. El acceso a la producción debe limitarse solo al equipo de soporte, con acceso limitado al desarrollador para solucionar problemas de producción. Los desarrolladores generalmente nunca deben hacer despliegues de código en caliente para la producción; los problemas de producción definitivamente podrían ocurrir, especialmente si los desarrolladores están bajo presión.

La administración definitivamente necesita manejar mejor los problemas aquí: será casi imposible mantener el desarrollo si el código se aplica directamente a la producción (y no entra en el control de código fuente).

El verdadero problema no es que los codificadores de vaqueros no usen el control de versiones. El verdadero problema es que ya han elegido alguna forma de hacer las cosas, y estás tratando de cambiar su proceso. El proceso elegido no incluye control de versiones. Todos los cambios en el proceso son difíciles, a menos que los propios programadores noten un problema. Si existe la sensación de que el sistema existente es lo suficientemente bueno, tratar de imponer algún sistema diferente es inútil. Somos el borg, serás asimilado. Por supuesto que están tratando de luchar para convertirse en borg.

Para su propia cordura, sugeriría configurar Git u otro DVCS en su propia máquina para que pueda realizar un seguimiento de los cambios. Importe los cambios de sus compañeros de trabajo a su repositorio a menudo. Resuelve los conflictos lo mejor que puedas. Esto lo protegerá parcialmente de la locura de sus compañeros de trabajo.

Usted mencionó que la gerencia ha dicho que los desarrolladores deberían usar el control de código fuente. Si quiere ser malvado, puede hacer cumplir esto al verificar los cambios en TFS y publicar periódicamente el repositorio, para así bloquear cualquier cambio que no esté en TFS. (Si también mantiene su propio DVCS, debe mantener los dos sincronizados). Su justificación para hacerlo es que está siguiendo órdenes de la gerencia. Si sus compañeros de trabajo se cansan de que se sobrescriban sus cambios, invítelos a usar TFS. Y siga haciendo cambios que no se hayan registrado. Continúe hasta que sus compañeros de trabajo cedan o lo despidan.

Bloquee cualquier servidor que no sea su desarrollo. Utiliza un administrador de configuración. Hacer compilaciones identificables regulares (contra etiquetas). Etiquete cada conjunto de cambios (es decir, 1 conjunto de cambios por error). También ponemos una etiqueta en cada compilación. Tener un sistema de tipo QA entre desarrollo y producción (como mínimo). Realice compilaciones en el sistema de control de calidad utilizando la etiqueta de compilación correcta. Dales pena por "romper la construcción".

Nunca me he encontrado con una situación en la que no pudiera volver a crear / solucionar un problema (que solo se muestra en producción). Sí, he pasado horas haciendo que el problema se vuelva a crear en un sistema de desarrollo (además, cuando lo descubras, puedes agregarlo a tu prueba de regresión).

Hicimos un proyecto con un grupo de contratistas de vaqueros que hicieron todas esas cosas malas. Paso 4 semanas limpiando después y luego pongo en práctica las prácticas anteriores. El proyecto no ha tenido problemas con ninguna de esas cosas desde entonces.

Citar:

El equipo no está acostumbrado a usar TFS

TFS resulta ser Microsoft Team Foundation Server.

Mi primer instinto dice: "esta es la última versión de Microsoft Visual SourceSafe"

Yo estaría del lado de ustedes compañeros de trabajo y realmente iría en contra de esto.