¿Hay algo malo en cómo estamos haciendo el control de versiones?

53

Trabajo con un equipo de programadores como analista de negocios. Acabamos de lanzar la versión 2.0 de nuestro producto y estamos trabajando en la próxima versión que se lanzará en 3 meses (es un producto de software interno). Lamentablemente, la versión 2.0 tiene algunos problemas que han tenido que solucionar y los implementaremos en un par de semanas. El problema es que tampoco queremos implementar los cambios en los que todavía se está trabajando y que no están programados para lanzarse durante otros 3 meses.

Los programadores decidieron que la forma de gestionar esto era que solo se registraría el código de los defectos, y el código de las nuevas mejoras se mantendría en las máquinas locales del desarrollador hasta que se realizaran. Tendré que obtener compilaciones locales de sus máquinas para probar porque si revisan el código y tenemos que sacar otro parche para corregir defectos, no queremos incluir esas mejoras todavía. También existe el problema de que el mismo archivo de código contiene tanto correcciones de defectos como mejoras, por lo que tienen que copiar el archivo de código localmente, luego hacer un cambio para corregir un error y verificarlo, luego reanudar el trabajo en las mejoras tomando el copia local que hicieron.

Parece bastante complicado: ¿hay una mejor manera de manejar este tipo de escenario? Estamos usando Team Foundation Server y Visual Studio 2010.

Ryan
fuente
113
Despide a tus programadores.
Bernard
11
Dales una rama cada uno. Hacer cumplir los registros diarios.
16
@Ryan La única excusa plausible que podrían haber tenido sería si se tratara de un proyecto heredado de algo antiguo como SourceSafe. Sin embargo, Team Foundation Server 2010 es una solución de control de fuente realmente buena que no debería tener problemas para administrar varias sucursales y realizar fusiones de estas ramas en la principal. Si no saben esto, entonces son obscenamente incompetentes y deberían ser despedidos. Sin embargo, es más probable que sean demasiado flojos o apáticos para sentirse molestos con las ramas y la fusión, por lo que te están alimentando de una línea.
maple_shaft
10
@ Jan_V Nada en SourceSafe es fácil.
maple_shaft
30
No estoy familiarizado con TFS, pero esta pregunta se lee como un anuncio de Mercurial o GiT.
Jim In Texas

Respuestas:

77

V2.0 debería haber tenido lo que usamos llamar una 'rama de estado estable' (utilizamos Perforce, no TFS) una vez que se lanzó. Cualquier corrección para v2 se habría realizado en esta rama y luego se habría propagado de nuevo a la rama de desarrollo v3 mientras también se estaban trabajando las características de v3, es decir, un defecto en v2 resultaría en un defecto también en v3.

Hacer que los cambios residan en las máquinas del desarrollador durante mucho tiempo probablemente resultará en una pesadilla de integración.

James
fuente
66
MS tiene un libro blanco sobre exactamente este tema (que cubre las cosas con mucho más detalle): vsarbranchingguide.codeplex.com/releases/view/38849
Richard
2
Y aún pueden hacer una rama de versión en TFS basada en la fecha y hora de compilación v2.0.
DaveE
2
Pasé mucho por esta publicación de blog, creo que está muy bien escrita (se relaciona con git, pero sigue siendo relevante) nvie.com/posts/a-successful-git-branching-model
BZink
50

Bueno, hay varias formas de abordar problemas como ese, generalmente cubiertos por la etiqueta de 'ramificación' , cada uno con su propio conjunto de beneficios y desventajas.

Pero enfoque elegido por sus desarrolladores ... vaya, lo citaré verbalmente para asegurarme de no haber leído mal ...

código ... se mantendrá en las máquinas locales del desarrollador hasta que se terminen ...

... ¡la forma como la anterior es probablemente la única que está totalmente, completamente equivocada!

Lo que hace que sea casi criminal para mí es que para TFS, hay una excelente y fácil de entender, Microsoft Team Foundation Server Branching Guidance : documento enorme y detallado con recomendaciones de estrategias de ramificación cuidadosamente adaptadas y explicadas para todo tipo de proyectos diferentes ( versión HTML aquí )

mosquito
fuente
66
En serio, los programadores deben ir y leer la Guía de ramificación de Team Foundation Server, y no escribir otra línea de código hasta que lo hayan hecho, lo hayan entendido y hayan creado ramificaciones separadas para las correcciones de errores 3.0 dev y 2.0.
Carson63000
@ Carson63000 está de acuerdo en que vale la pena leerlo incluso para personas que no son TFS (como yo). La forma en que los chicos de Microsoft clasifican los proyectos y especialmente cómo establecen los factores a considerar al elegir la estrategia de ramificación adecuada son independientes de las herramientas y son un buen alimento para el pensamiento.
mosquito
40
  1. Sus desarrolladores tienen un malentendido fundamental sobre cómo usar el control de versiones.
  2. No entre en una discusión sobre el software de control de versiones "correcto". Este no es el problema.
  3. Cada modificación de código hace que el problema sea más difícil de solucionar.
  4. CUANDO decidan hacer lo correcto, no podrán continuar los cambios de código mientras arreglan las cosas. DEBE detener todo el desarrollo y obtener el código en el control de versiones.
  5. Los desarrolladores deben sentir el dolor lo suficiente como para al menos sentarse y hablar sobre ello.
  6. Todo el software de control de versiones admite conceptos básicos:
    • TODO el código va al repositorio de control de versiones.
    • Todos los archivos de código tienen números de versión. Estos números se incrementan automáticamente a medida que se vuelve a registrar el código.
    • Un TAG marca todos los archivos de código de una (y en una) versión particular. Por lo tanto, podemos etiquetar el lanzamiento de la versión de software 1, por ejemplo.
    • una RAMA es un "desvío" del tronco principal .
      • Cualquiera y todos los cambios realizados en una rama no afectan el tronco.
      • Opcionalmente, puede fusionar los cambios de rama nuevamente en el tronco principal en algún momento.
      • Por lo tanto, podemos experimentar sin temor a estropear "lo bueno".
  7. Todos ustedes deben obtener el control de versiones "salto de fe" como lo llamo. CONFÍE en que seguir las reglas básicas mantendrá las cosas claras. La inexperiencia nos hace pensar lo contrario, confía en mí.
  8. Aquí hay un tutorial decente. Es lo suficientemente general y completo como para que no necesite buscar muchas otras fuentes.

editar

  • Ponga el control de versiones en su computadora de trabajo.
    • Puede hacerlo ahora mismo sin la coordinación del equipo
    • Incluso con el control de versiones del equipo, recomiendo esto
    • Si su equipo utiliza Git o Mercurial, está utilizando un repositorio local independiente. Así es como funciona el control de versiones distribuidas.
    • Puede usar diferentes programas de VC de su equipo. Nuestro equipo usa Subversion, yo uso Mercurial localmente. Los metarchivos de software VC (".svn", ".mg", carpetas ocultas) no entran en conflicto.

No estás actuando como un repositorio de equipo de facto. Es para administrar su propio trabajo, refactorizar esfuerzos, etc. y CYAing usted mismo mientras el equipo continúa FUBAR la base del código.

fin editar

radarbob
fuente
3
Nitpick: "Todos los archivos de código tienen números de versión. Estos números se incrementan automáticamente" Algunos VCS (por ejemplo, Subversion, Git) tienen ID de versión por repositorio en lugar de por archivo, y las ID de versión no son necesariamente numéricas (Git). Por supuesto, el punto básico sigue en pie.
sleske
versiones "por archivo / por repositorio (sitory)". Sí. Esta es una diferenciación fundamental del software VC. He usado ambos tipos: "country AND western" (+1 para quien conozca esta referencia). Me gusta más el modelo "por repo".
radarbob
13

Lo que está describiendo es una forma terrible de usar el control de versiones. Debería haber una rama hecha para la versión 2.0, o una etiqueta o algún identificador. De esa forma, se pueden contener modificaciones a esa versión y se puede seguir desarrollando más.

Este artículo puede darte algunas ideas. Está escrito teniendo giten cuenta, pero no hay razón para que no funcione mercurialtan bien. Me doy cuenta de que no estás usando ninguno de estos, pero ese también es un problema que deberías considerar solucionar.

jdl
fuente
99
¿Qué hay de malo en usar TFS?
Bernard
2
Depende de lo que intentes lograr. Los pros y los contras son un tema común en SO. Este es un punto de partida decente. stackoverflow.com/questions/4415127/…
jdl
44
Los sistemas de control de versiones distribuidos no siempre tienen sentido.
maple_shaft
3
-1: A pesar de lo que afirman los evangelistas, el control de revisión distribuido no es la respuesta a todos los problemas, y no resolvería este.
mattnz
3
@Ant: Quizás tenga razón, pero en el contexto de la pregunta original, no creo que importe si TFS se está utilizando para el control de la fuente. Mientras TFS admita la ramificación, debe ser utilizado por el equipo de desarrollo del OP.
Bernard
7

Respuesta rápida: El equipo de desarrollo debe tener una rama de producción separada para mantener la base de código implementada V2.0 separada del tronco principal .

Todas las correcciones de errores deben hacerse primero en esa rama y luego probarse e implementarse en otras ramas, para mantener el código sincronizado .

Su proyecto también debería tener varios entornos for health developmentcomo Prod, Staging, QA y Dev (a veces UAT). Estos entornos deben configurarse antes de ir a la versión de producción.

En general, estar preparado para errores y modificaciones es la forma de admitir una aplicación lanzada.

Como se mencionó TFS como control de versión, también he compilado una lista de artículos que serán útiles para establecer entornos de desarrollo de salud:

EL Yusubov
fuente
4

No, porque mientras está usando un VCS, no está haciendo el control de versiones.

El concepto central para el control de versiones es rastrear la diferencia a lo largo del tiempo, está PLANEANDO registrar algunas diferencias, pero en este momento la mayoría de sus cambios no se registran.

Como otros han dicho, deberías estar usando ramas. Una vez que tenga esa configuración, debe verificar todos los cambios funcionales (es decir, no cada pulsación de tecla, pero cada vez que arregle un error, agregue una función, elimine una función o complete un cambio de modo que aún se construya y funcione).

jmoreno
fuente
0

Soy desarrollador y recibimos diferentes códigos de sucursal y bases de datos para las correcciones de la versión actual y diferentes para las mejoras y para la versión consecutiva posterior.

Una vez que se realizan nuestras correcciones, se combinan con la producción y se implementan, obtenemos una nueva sucursal nueva para volver a trabajar en mejoras.

Además, seguimos una práctica como si tuviera 10 soluciones para mi versión actual

Yo escribo como

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

De manera similar para otras correcciones, solo hago esto para cada línea que cambio o agrego para corregir. Y solo compara y comprométete. Del mismo modo, si estuvieran haciendo paralelo en la misma rama, pueden usar

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fcomando y tipo //Start Iteration 2, Fix No-1, Branch No-"ABC" para buscar en la solución completa ayuda mucho a encontrar ubicaciones exactas, archivos donde se cambia el código y tomar código nuevo solo esa parte se puede usar para confirmar.

Shilpa
fuente