¿Cómo puedo convencer a los programadores de cowboy para que utilicen el control de código fuente?

No es un problema de entrenamiento, es un problema de factores humanos. Ellos no quieren, y están creando bloqueos de carreteras. Enfréntate a las dinámicas rotas del grupo, cuál es la causa de su objeción: por lo general, el miedo, es solo miedo al cambio, o es más siniestro.

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

¿El sistema los obliga a hacerles la vida difícil de alguna manera? Averigüe qué es y cambie el sistema para invalidar la objeción. Repetir hasta terminar.

Sugiero mirar GIT o Mercurial. Puede crear un repositorio en cada árbol de código fuente, ni siquiera se darán cuenta y podrá seguir pirateando como lo hacen ahora. Puede hacer un seguimiento de los cambios que han pirateado en la base del código, realizar confirmaciones, combinarlos en otros árboles de origen, etc. Cuando lo vean hacer una fusión de una semana de esfuerzo en otro producto en segundos, pueden cambiar sus ideas. Cuando retrocedes uno de sus errores con un solo comando y les guardas el culo, incluso podrían agradecerte (no cuentes con ello). En el peor de los casos, te ves bien frente al jefe y, para obtener una bonificación, haz que se vean como los vaqueros que son.

  

La fusión llevarí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 las características que ya tiene en una rama (término utilizado de manera no uniforme) a otra.

Si fuera tú, reconsideraría mis perspectivas profesionales ...

  

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

Falso.

  

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

Eso no tiene nada que ver con el control del código fuente y todo lo relacionado con la capacitación. La capacitación es fácil, barata, 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 problema de entrenamiento. Otra vez. Nada que ver con el control del código fuente y todo lo relacionado con la capacitación.

  

Los desarrolladores siguen desconfiando del control de origen y, por lo tanto, complican el problema al no utilizar el control de origen

Deben recibir capacitación sobre cómo usar el control del código fuente. Reduce los costos, reduce los riesgos, simplifica las cosas y es más eficiente. Es una inversión única que paga dividendos en cada momento.

  

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

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

Actualizar

  

Los desarrolladores argumentan que la modificación directa del control de origen ahorra tiempo.

Ya que están equivocados, es importante recopilar datos para demostrar con precisión qué tan 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 recompensa es

A) Identifique que el costo a largo plazo es más alto que el valor aparente a corto plazo.

B) Identifique las recompensas reales que realmente existen y que hacen que la corrupción a corto plazo (es decir, los cambios directos) parezca más valiosa que el control correcto del código fuente a largo plazo. ¿Quién recibe una palmadita en la cabeza por hacer algo incorrecto? ¿Qué tipo de palmaditas en la cabeza reciben? ¿Quién 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) Recomiende 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 motivos.

D) Capacite a la gente en las recompensas que encontró por su valor a largo plazo; valor que es claramente mayor que la respuesta rápida a corto plazo.

Los desarrolladores que se nieguen a usar el control de fuente / versión deben ser despedidos, así de simple. Como ya ha señalado, los riesgos y costos inherentes de NO usarlo superan cualquier gasto general en que incurran en muchos, muchos órdenes de magnitud. Cualquiera que intente argumentar en contra de esto simplemente no debería estar involucrado en el desarrollo de software y me negaría rotundamente a trabajar con esas personas.

Primero solucionamos el problema, configurando un servidor de integración continua para construir nuestro control de código fuente en dev. En segundo lugar, bloquee el acceso de la carpeta a 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 se puede reproducir el error localmente, pero aparte de eso, es mejor poder trabajar, registrar y seguir adelante, sabiendo que el servidor de CI lo enviará automáticamente a dev.

Escucho tu dolor. Entré en un par de lugares de trabajo para descubrir que 'control de código fuente' era una carpeta compartida en una unidad de red. Por lo general, el problema no es porque crean que el enfoque es superior a cualquier otra cosa, simplemente funciona y nunca se ha introducido en un flujo de trabajo que integre con éxito el control de la fuente.

Con la estructura del equipo de la Tierra plana que ha explicado, el hecho de que se empuje el cambio de arriba hacia abajo puede no ser la mejor manera de abordar la situación. Un método que vale la pena probar es comprar directamente de uno o dos de los otros desarrolladores para permitir que el concepto adquiera impulso. Una vez que tengas incluso otro desarrollador a bordo, será mucho más fácil distribuirlo al resto del equipo. Lentamente, introdúzcalos en el concepto, digamos, comience a trabajar en un pequeño proyecto paralelo, comience a trabajar en Git , o incluso bifurque algo alojado en < a href="http://github.com/"> 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 con un montón de pequeños cambios a la vez, se vuelve alienante. Una vez que comprendan cómo funciona el control de la 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 así lo desea, esto será especialmente efectivo para resaltar las ventajas del control de código decente.

Si eso falla, ejecuta.

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

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

Tome una copia de la última fuente, vuelva a estructurarla para que sea compatible con el control de versiones, cree un nuevo proyecto con una estructura útil y orientada al futuro (descubra cómo va a manejar las sucursales, donde coloca dependencias de terceros) etc). Probablemente tendrás que hacerlo en tu propio tiempo.

Luego arrastre a sus compañeros de trabajo y a la gerencia a una sala y muéstreles cómo se ve el desarrollo de software en el siglo XXI. Ilustre las fallas con su sistema actual y muestre cómo se eliminan con su nueva estructura.

También tendrá que establecerse como el Guardián de la Fuente, ya que parece ser el único que se preocupa, depende de usted obligar a las personas (con cualquier medio técnico o psicológico a su disposición) para atenerse al plan. Asegúrese de que la cosa solo que se dirige a un cliente provenga de una máquina de compilación fuera del control de origen. Ritualmente humillar a las personas que rompen las reglas y causan estragos. Sobórnalos con donas ... lo que sea que funcione.

Si todo esto parece demasiado esfuerzo, entonces (como se ha dicho en casi todas las demás respuestas) - consiga otro trabajo. No valen tu tiempo.

Este es un buen ejemplo de un proyecto en el que las malas prácticas se han utilizado de manera tan generalizada que resulta prácticamente imposible repararlo. Repararlo requeriría una congelación, por lo que todo se puede limpiar sin interrupción. Desafortunadamente, tales proyectos generalmente son (por razones obvias) demasiado buggy para ser congelados por varios meses, los errores críticos deben ser arreglados cada dos días.

Usted podría tener la tentación de dividir el proyecto para crear una versión limpia mientras que 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 deslizarse en tales prácticas hace improbable que mantienen registros sobre los cambios que hacen). La versión limpia está desactualizada, la versión sucia aún funciona un poco, ¿y qué sucede? La versión limpia se ha descartado, lo que no se ha dicho es correcto.

Paso 1 - ¡Gerente incompetente de incendios!

Si no puede realizar el paso 1, intente que el administrador limite la implementación a los scripts que solo se toman del control de origen. Si los desarrolladores (que no deberían tener derechos de producción en prod, ver el paso 1 si lo hacen) quieren que sus cosas se implementen, deben proceder del control de código fuente. Eso resolvió nuestro problema de no usar el control de código fuente muy bien cuando empezamos a usarlo para cosas de base de datos y código C #.

¿Cómo puede alguien no querer diferentes versiones de sus archivos y la capacidad de ver las diferencias? Olvida la ramificación y cualquiera de las cosas complejas. Ni siquiera consiguen lo básico. La modificación directa de 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 perezosos. Eso es una pérdida de tiempo. Todo lo que puedes hacer es entrenar a tu manager. A la gerencia le debe gustar el control de la fuente porque les gustan todas las formas de control. Los hace sentir importantes. Atornille a los demás; fijar 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 vacante o que lo contraten en su tienda.

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

Primero, diríjase a la administración para que se involucren con el traslado y la aplicación del control de código fuente. Luego vaya a lo que debe hacerse para que todo funcione, incluso si eso significa trabajar directamente en el servidor. Comience el proceso de obtener todo en el control de código fuente.

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

Por su descripción, parece que hay uno o más problemas con la situación: o el equipo de desarrollo está fuera de control o se implementó una mala solución de control de fuente. De cualquier manera, es responsabilidad del equipo de desarrollo usar alguna solución de control de origen: la modificación directa del código fuente en el servicio de producción solo está implorando que ocurran problemas.

Desde mi experiencia, el primer paso que debe darse inmediatamente 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; el código de producto es presumiblemente la base que su equipo está desarrollando. Es posible que este paso deba aumentarse mediante una combinación con el código que está flotando en el sistema de control de origen existente. El código debe pasar de dev a Integration / QA (o ambos), y luego a la etapa o etapa / producción.

A continuación, la administración debe exigir el uso del control de origen. Sencillamente, si la compilación no provino del sistema de control de origen, el código no debería implementarse en producción. El acceso a la producción debe limitarse únicamente al equipo de soporte, con acceso limitado al desarrollador para solucionar problemas de producción. Por lo general, los desarrolladores nunca deben realizar implementaciones en caliente de código en la producción; los problemas de producción definitivamente pueden ocurrir, especialmente si los desarrolladores están bajo presión.

Definitivamente, la administración necesita controlar mejor los problemas aquí: será casi imposible mantener el desarrollo si el código se aplica directamente a los productos (y no ingresa al control de código fuente).

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

Bloquea cualquier servidor que no sea su desarrollo. Utilice un administrador de configuración. Hacer compilaciones identificables regulares (contra las etiquetas). Etiquete cada conjunto de cambios (es decir, un 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). Hacer compilaciones para 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 tratando de recrear el problema 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. Pasé 4 semanas limpiando y luego puse las prácticas anteriores en su lugar. El proyecto no ha tenido problemas con ninguna de esas cosas desde entonces.

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

Has mencionado que la administración ha dicho que los desarrolladores deberían usar el control de código fuente. Si quiere ser malvado, puede imponer esto marcando los cambios en TFS y publicando periódicamente el repositorio, por lo tanto, anule los cambios que no estén en TFS. (Si también está manteniendo su propio DVCS, debe mantener los dos sincronizados). Su justificación para hacerlo es que está siguiendo las órdenes de la administración. Si sus compañeros de trabajo se cansan de que se sobrescriban sus cambios, invítelos a usar TFS. Y mantén todos los cambios que no se hayan registrado. Continúa hasta que tus compañeros de trabajo renuncien o te despidan.

Cita:

  

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"

Estaría del lado de ustedes, compañeros de trabajo e iré realmente en contra de esto.