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

62

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?

P.Brian.Mackey
fuente
24
Pieza clave de la información que falta: ¿Cuál es su papel en el equipo?
Morons
116
¿La vida es realmente lo suficientemente larga como para desperdiciar años trabajando en un lugar como ese? Usted tiene un equipo de compañeros de trabajo que no desean trabajar de manera competente y profesional, y una gerencia a la que no le importa. Puedes hacerlo mejor.
Carson63000
8
Acerca de no ser utilizado para el control de origen: si este es un proyecto del mundo real, es hora de acostumbrarse al control de origen.
Compman
14
Cambie su lugar de trabajo o cambie su lugar de trabajo. Lo que decidas, no lo dudes.
Goran Jovic
11
La idea de que un desarrollador haya usado previamente el control de código fuente y no lo ame está casi fuera de mi comprensión. ¿Quizás lo usaron mal?
jhocking

Respuestas:

92

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 ...

mattnz
fuente
13
-1, "Ningún desarrollador profesional hoy, o durante los últimos 20 años, se ha resistido al control de la fuente". - Total sin sentido, y totalmente dogmático. Sospecho que estás definiendo 'profesional' como 'alguien que se desarrolla como tú'.
GrandmasterB
68
@Grandmaster: ¿Estás diciendo que es aceptable que un programador no use el control del código fuente, o estás objetando que yo sea demasiado dogmático? De todas las cosas que puedo pensar que no están abiertas a negociación en 2011, el control de la fuente estaría en la parte superior de mi lista. Parece que otros 27 están de acuerdo conmigo. Un DVD grabado con cada lanzamiento, o una copia del árbol de origen en una carpeta con una fecha es posiblemente el control de origen.
mattnz
8
Digo que la afirmación de que todos los profesionales usan el control de fuente es demostrablemente falsa . Sé mucho que no, algunos que lo han 'resistido'. El control de código fuente es una herramienta, como un IDE. Los profesionales usan las herramientas que consideran más adecuadas para el trabajo. Si quieren usar el control de fuente, bien por ellos. Si no lo hacen, esa es su prerrogativa. Afirma que su "no está abierto a negociación" es irrelevante: no sabía que fue nombrado el árbitro único y final de cómo la gente debería escribir software. Personalmente, no soy tan presuntuoso como para suponer que conozco mejor a todos los demás.
GrandmasterB
39
@GrandmasterB: se podría argumentar en contra de prácticamente cualquier cosa con la presunción de que aceptamos evidencia anecdótica. Por supuesto, el 100% de los desarrolladores no utilizan el control de código fuente. Por supuesto, hay un caso o un pequeño porcentaje de casos límite exitosos. La mejor práctica es utilizar el control de fuente. Es seguro asumir que cualquier desarrollador que dice que trabaja en un equipo que no necesita control de fuente es un vaquero. No es que los vaqueros no puedan codificar, porque de hecho pueden hacerlo y, a menudo, muy bien. Por lo general, no pueden trabajar con otros que también pueden hacerlo.
P.Brian.Mackey
44
@MattThrower: Incluso si un desarrollador está trabajando solo, aún sugeriría un SVN local. Honestamente, el único argumento "convincente" (es decir, estoy convencido de que la persona que toma la decisión lo está haciendo desde una posición de conocimiento) que he escuchado contra el control de la fuente es este: "Se nos prohíbe permitir la existencia de datos históricos copias de nuestro código, incluso si la copia actual pudiera algún día corromperse, lo que nos haría perder todo nuestro trabajo ". No me gusta ese argumento, pero he oído que a veces sucede con el trabajo secreto del gobierno.
Brian
31

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.

S.Lott
fuente
He sugerido entrenamiento. Más de una vez, muchas veces. Tuvimos sesiones de entrenamiento, dos o tres, pero fallaron. Solo me dieron ~ 1 hora para entrenarlos en TODO TFS. Y el seguimiento fue pobre. Me dieron el viejo "sigue la zanahoria", viene el entrenamiento ... pero no pasa nada. Trato de impulsar el problema, pero después de tantos intentos empiezo a sentirme como el malo simplemente porque soy el hombre extraño aquí. Les dije lo que es incorrecto, pero simplemente no están de acuerdo. La gerencia dice "sí, use TFS", pero la aplicación es 0.
P.Brian.Mackey
3
"ellos fallaron". Falso. Fueron socavados por un sistema de recompensa que recompensa el mal comportamiento. Se requiere más entrenamiento. Solo que la capacitación necesita arreglar el sistema de recompensas, no simplemente explicar cómo apuntar y hacer clic en la herramienta.
S.Lott
1
@ P.Brian.Mackey: "Tuvimos sesiones de entrenamiento, dos o tres". Por favor, actualice su pregunta para contener la totalidad de la historia. Asegúrese de que su descripción esté completa en la pregunta. No introduzca nuevos hechos en los comentarios sobre una respuesta específica.
S.Lott
1
Ok, la obsesión con el entrenamiento es incorrecta: es un problema de gestión / política / ambiente del cual el entrenamiento es un aspecto, pero todo el entrenamiento en el mundo no sirve si pueden ignorarlo mientras aprenden (se hunden o nadan) independientemente del entrenamiento si no pueden hacer otra cosa
Murph
66
Uno de mis compañeros de clase de una clase VLSI hizo un transistor de unos pocos nanómetros de ancho y un par de millas (¡sí, millas!) De largo que se ajustaba a las especificaciones. Su respuesta a mí fue "Todo lo que sé es que mi mierda funciona". Tenía más tolerancia para las personas en la universidad. Ahora odiaría terminar con alguien así en mi equipo. Creo que algunos equipos deberían ser entrenados, y algunos deberían despedirse. La vida es demasiado corta para odiar el trabajo de uno / colegas.
Trabajo
17

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.

papilla
fuente
10

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.

CaffGeek
fuente
Buena sugerencia, genial de hecho. Pero, la gerencia me dio luz roja sobre CI. No hay fondos para una VM o servidor físico. No hay tiempo asignado para la configuración tampoco.
P.Brian.Mackey
77
¿Fondos para un servidor CI? Se financia a sí mismo. Muestre cuánto tiempo lleva hacer una implementación manual con un video si es necesario. Luego explique que esto se hace varias veces al día. Veces varios desarrolladores. Y debería pagarse en tiempo ahorrado en un mes.
CaffGeek
66
Demonios, entonces ejecuta Jenkins en tu propia máquina.
Matthew Flynn
55
+1 para bloquear la estructura de carpetas. Quite sus permisos de servidor y tendrán que seguir la ruta correcta (a través del control de origen)
Mauro
8

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.

Kim Burgess
fuente
También creo que cuando los desarrolladores se muestran complacidos por estar atascados en el pasado, generalmente siguen el axioma de "si no está roto, no lo arregles". La mayoría de los lugares donde trabajé tenían la misma mentalidad de vaquero, porque 1. porque hay una gran brecha de alfabetización informática entre los desarrolladores y sus gerentes o 2. hay tan pocos desarrolladores que realmente no hay una jerarquía de habilidades o un empleado sénior en su empresa significa "Trabajé 10 años haciendo lo mismo que hice en mi primera".
Chris C
2
Una carpeta de red compartida con instantáneas es una forma de control de versiones. Una forma muy pobre para estar seguro, pero es una de todas maneras.
Joeri Sebrechts
44
Siempre pregunto qué sistema de control de código fuente está en uso en una entrevista. Cuando el CTO de una compañía dijo "¿Qué es eso?", Me escapé.
Zachary K
6

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.

MarcE
fuente
jajaja, buenas sugerencias. La mayor parte de esto ya se ha hecho. El gerente dice "sí, tenemos que usar el control de fuente". Pero, el equipo no usa el control de fuente. Le digo al gerente y mgr simplemente dice "sí, tenemos que usarlo". Nadie es regañado. Sin aplicación
P.Brian.Mackey
3
@ P.Brian.Mackey - A veces solo tienes que ir todo BOFH . Una vez que me fui de vacaciones y un contratista que trabajaba para mí pasó toda la semana navegando por sitios web de citas. Cuando volví y descubrí esto, su equipo desarrolló un problema de acceso TCP / IP inexplicable que yo era incapaz de solucionar. Haga que su jefe les quite sus derechos de piratear directamente en el servidor y los obligue a pasar por TFS para la implementación y pronto limpiarán su acto o renunciarán, de cualquier manera que gane.
Mark Booth
La idea del Guardián de la Fuente es buena. Puede hacer que le envíen sus cambios, o al menos hacerle saber que hicieron algunos y actualizar su repositorio desde el diff con prod. O ejecute fswatchy haga que se comprometa con el repositorio cuando cambien los archivos.
Joe McMahon
4

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 #.

HLGEM
fuente
4

¿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.

JeffO
fuente
3

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.

usuario281377
fuente
2

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.

Jacob Schoen
fuente
2

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).

JW8
fuente
1

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.

tp1
fuente
1

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.

Jonathan
fuente
0

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.

Pablo
fuente
-3

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.

Niels Basjes
fuente
1
Team Foundation Server es una bestia bastante diferente a SourceSafe. La comparación no es justa.
pap
El núcleo de mi argumento tiene muy poco que ver con TFS. El problema fundamental es la falta histórica de utilizar el control de fuente de cualquier tipo.
P.Brian.Mackey
¿Saben que es diferente? No lo hice
Niels Basjes
@Hiels Basjes - ¿Saben qué es diferente?
P.Brian.Mackey
Ese TFS es diferente de Source Safe.
Niels Basjes