2008-09-04 14 views
12

Mi lugar de trabajo actual se encuentra actualmente en una transición, la nueva propiedad se ha hecho cargo, las cosas finalmente se están estandarizando y se están aplicando las pautas adecuadas.Cómo convencer a una empresa para cambiar su Source Control

Pero todavía estamos usando VSS, realmente no hay ninguna razón para usarlo, entonces eso es lo que se configuró inicialmente. No utilizamos Visual Studio, o cualquier herramienta realmente que lo requiera específicamente.

¿Cuál sería el mejor argumento absoluto que puedo mencionar para ayudar a convencerlos de que ir a algo como Subversion sería una solución mucho mejor, a la larga.

Respuesta

16

VSS confía plenamente en los clientes para gestionar la base de datos. Si un cliente deja de conectarse en el medio de una escritura a través de la red en el momento equivocado, su archivo se descarta en el servidor. No solo el consejo, sino toda la historia. Espero que tengas una buena copia de seguridad. He pasado por eso. Son malas noticias.

El uso de VSS sobre VPN u otras conexiones remotas es abismal. Está utilizando SMB para transferir los datos, y tiene que recuperar el archivo y todos sus deltas solo para obtener la sugerencia. Asqueroso.

He visto a VSS comenzar a actuar con 1 GB de datos. Errores de base de datos, etc. MS (en algún lugar de las Preguntas frecuentes o KB) dice que 2 GB es realmente el límite máximo de seguridad. No hay buenas herramientas de administración (los clientes ejecutan el asilo), por lo que realmente no recibe ninguna advertencia al respecto.

Cualquier cosa con un proceso de servidor para proporcionar cierto nivel de transacciones y control de integridad es una solución superior.

1

Cualquier documento que pruebe el cambio reducirá los costos. En su defecto, gráficos y cuadros multicolores. Tal vez una presentación de power point.

+0

Los costos más bajos NO son el principal impulsor de un sistema de control de fuente. – DJClayworth

8

El mejor argumento debería ser el motivo por el que desea que cambien a subversión. :)

No sé absolutamente nada sobre VSS, pero me viene a la mente la frase "si no está roto, no lo arregles". Debe mostrarles a sus gerentes que VSS está roto y necesita ser reparado. Aún mejor si puede mostrar a la administración cómo les ahorraría dinero.

+0

Incluso si otras personas dicen que VSS está roto y corrompe la fuente, si la compañía no ha tenido malas experiencias, entonces deben ser muy cautelosos sobre el cambio. Cambiar el sistema de control de fuente es una empresa enorme y arriesgada, incluso si vas a algo "mejor". – DJClayworth

2

Por repasando las características buen control de la fuente trae:

  • capacidad de ver fácilmente registros de quién hizo qué, cuándo, y en qué orden, a qué archivos
  • mantener un historial de versiones anteriores de todo lo
  • volver fácilmente y reproducir una versión específica de sus archivos desde cualquier versión anterior, para reproducir más fácilmente errores reportados en versiones anteriores
  • capacidad go recuperar el código eliminado o eliminar los cambios no deseados, sin tener que preocuparse de perder datos en el proceso
1

Internet está plagado de artículos bien escritos sobre los defectos de VSS. Recogería esto como evidencia para alejarme de VSS. Encuentre un requisito clave que VSS no puede admitir (trabajo remoto, soporte en otros sistemas operativos, integración de herramientas) y úselo para manejar su problema. Luego necesita encontrar un sistema de control de fuente que coincida con los requisitos de su organización. ¿Está seguro de que Subversion es ese sistema? Configure una demostración de su sistema elegido y utilícelo para demostrar su valor.

Implementé este cambio en un empleador anterior (primero en CVS, y luego en SVN), y si bien fue exitoso tuvimos que construir muchos bits al límite y confiar en una gran cantidad de veces (a veces no confiable) abierto proyectos fuente para obtener todas las herramientas que necesitábamos. En retrospectiva, debería haber considerado intentar evaluar herramientas profesionales como Perforce, Vault o incluso Team System. Una vez evaluados estos, podría haber realizado un juicio de valor adecuado sobre si CVS/SVN valían su precio "gratuito".

1

ser capaz de manejar la bifurcación y bifurcación es un comienzo.

Pruebe usar subversion por un tiempo en paralelo a vss, lo más probable es que encuentre muchos argumentos para convencer a su jefe. Si no lo haces, tu jefe tiene razón, no hay razón para cambiar.

1

Haz que busquen en google 'problema de vss', 'corrupción segura de la fuente' o simplemente mira la página Wiki para obtenerla. Eso debería convencerlos de que probablemente no sea una cosa viable a largo plazo para que apueste una parte tan vital de su negocio.

¿Qué tan grande es tu equipo? (es decir, me refiero a cuántos miembros, no si eres o no evasores de ensaladas). Una vez que empiezas a tener más de media docena de usuarios bastante activos, VSS te va a dar dolores de cabeza.

Tengo serias dudas de que Microsoft lo use (de hecho, ¿no usan una versión personalizada de Subversion o CVS?) Y usted debe preguntarse a sí mismo: si la compañía no come su propio alimento para perros, ¿por qué ¿te lo comiste?

0

Incluso si no está roto, existe la posibilidad de que migre desde VSS. Primero y más trivialmente, no tendrá que comprar nuevas licencias de VSS. En segundo lugar, hay muchos ejemplos de deficiencias en el producto VSS (algunos también reconocidos por MS). La curva de aprendizaje para SVN es al menos tan baja como para VSS, y si los desarrolladores están más contentos con su sistema de control de origen, es más probable que lo utilicen temprano y con frecuencia. Eso se traducirá en mucho menos riesgo para su empresa, y ese es un buen beneficio.

1

La respuesta básica es que tiene que demostrar que la conmutación cumple con las necesidades de la empresa. Por ejemplo:

  1. menor coste de desarrollo
  2. horario más corto (otra sombra de # 1)
  3. más apta para satisfacer los requisitos del proceso (como los requisitos de software de trazabilidad, o construir reproducibilidad, etc).

Haciendo el caso de estas cosas requiere también algo cuantitativo, no sólo "vamos a costos más bajos, porque esta es la razón manera de hacerlo!".

Una cosa a tener en cuenta es que es demasiado fácil para un desarrollador convencerse de que sería beneficioso realizar el cambio sin pasar antes por los filtros básicos de negocios. Una vez que eso sucede, terminas con desarrolladores que no están contentos con sus herramientas y se sienten doblemente frustrados porque piensan que la gerencia no los escuchará. Si no puede marcar una de las cosas anteriores, no tendrá ninguna posibilidad de persuadir a la administración de algo (a menos que la administración sea incompetente, pero eso es por otra cuestión).

1

¿Por qué Subversion over VSS?

  • software gratuito
  • más fácil de manejar
  • "check-ins" son atómica!
  • Fácil de sucursal y Merge
  • desarrollo Continuación (es decir VSS es sin salida)
  • mejores herramientas para el seguimiento de los cambios y los registros de visualización
  • conjunto de herramientas y la plataforma agnóstica, pero también se integra con muchas herramientas

Hice la propuesta a mi gerente, y fue una venta bastante fácil. Descubrí que es mucho más fácil de usar, especialmente para la bifurcación (nuestro proyecto tardó 5 horas en "compartir y fijar" en VSS, y luego cada operación tomó más tiempo para completarse).

4

@Adam Davis: Uhhh en realidad Adam, VSS es un sistema de control de fuente horrible. Tiene una larga historia de corrupción de la historia y pérdida de datos. Es terrible en la fusión, no maneja bien a muchos desarrolladores y es muy lento. Además, la historia es pobre. Microsoft ya no lo soporta, notará que nunca lo usaron para su propio desarrollo interno y ahora ni siquiera lo venden a favor de una solución más moderna (VSTS). En resumen, si tiene que elegir entre VSS y cualquier otro tipo de control de fuente, vaya con la alternativa.

1

Tengo previously written acerca de por qué VSS no es una buena idea. Es posible que pueda obtener algo de información de eso. También this article y this one contienen más información.

VSS 2005 ha empapelado algunas de las grietas en 6.0, pero no de una manera particularmente convincente. La misma base con muerte cerebral permanece.

0

@Jason: VSS está roto.

Creo que el método más poderoso para motivar un cambio de VSS es señalar qué tan crítico es un activo su código fuente. Tomar riesgos con su integridad no es una buena opción comercial.

Agregue que sus programadores son los creadores de este activo, y que para que sea más fácil para ellos ser productivos significa más valor en su activo de código fuente. Joel en Software a menudo habla de cómo invertir en sus programadores es una gran victoria para su compañía.

Las demás respuestas aquí describen todas las razones específicas que puede señalar al presentar su caso.

0

Además de los puntos técnicos que se proporcionan en otras respuestas, puede haber razones no técnicas están al acecho de que usted debe estar preparado para responder a:

Debe investigar si su empresa tiene algún tipo de política en contra (o miedo equivocado de) software de código abierto. Si la compañía o sus abogados no entienden los pormenores de las licencias que "infectan" el código propietario y las que no, así como también lo que puede hacer con el código fuente abierto que no afecta su código de propiedad, usted lo hará. tienen dificultades para lograr que cambien de una herramienta propietaria a una herramienta de código abierto. (Y puede tener un trabajo de educación más grande en sus manos.)

Al abogar por el cambio de propietario (por ejemplo, VSS) a código abierto (por ejemplo, subversión) también deberá estar preparado para defender la calidad del código y la falta de cualquier necesidad de garantía u otros derechos de contrato con respecto al código.

Cuestiones relacionadas