¿Hay algún problema con la forma en que estamos haciendo el control de versiones?

V2.0 debería haber tenido lo que utilizamos, llamado "rama de estado estable" (usamos Perforce, no TFS) creado para ello 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 las funciones de v3 también se estaban trabajando, es decir, un defecto en v2 resultaría en un defecto también en v3.

Si los cambios residen en las máquinas del desarrollador durante mucho tiempo, probablemente resultará en una pesadilla de integración.

Bueno, hay varias maneras para lidiar con problemas como ese, generalmente cubiertos por etiqueta 'branching' , cada uno con su propio conjunto de beneficios y desventajas.

Pero el enfoque elegido por sus desarrolladores ... gee, lo citaré verbalmente para asegurarse de que no haya leído mal ...

  El

código ... se mantendrá en las máquinas locales del desarrollador hasta que estén listas ...

... ¡la forma como la de arriba es probablemente la única que está totalmente equivocada!

Lo que hace que sea casi criminal para mí es que para TFS, hay una excelente, fácil de entender, Guía de bifurcación de Microsoft Team Foundation Server versión HTML aquí ).

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 versión "correcto". Este no es el problema.
3. Cada cambio de código hace que el problema sea más difícil de solucionar.
4. CUANDO ustedes deciden hacer lo correcto, no pueden 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. El dev debe sentir el dolor lo suficiente como para al menos sentarse y hablar de 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 a) versión particular. Por lo tanto, podemos TAG el lanzamiento de la versión de software 1, por ejemplo.
   • un BRANCH es un "desvío" del tronco principal .
     • Todos y cada uno de los cambios realizados en una rama no afectan al tronco.
     • Opcionalmente, puede fusionar cambios de rama nuevamente en el tronco principal en algún momento.
     • Por lo tanto, podemos experimentar sin miedo de arruinar "las cosas buenas".
7. Deben obtener el control de versión "salto de fe", como yo lo llamo. CONFÍE en que seguir las reglas básicas mantendrá las cosas en orden. 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 explorar muchas otras fuentes
   • Control de versión, mejor explicado

edit

• Pon el control de versión en tu computadora de trabajo.
  • Puede hacerlo ahora mismo sin la coordinación del equipo
  • Incluso con el control de versión del equipo, lo recomiendo altamente
  • Si su equipo usa Git o Mercurial, está usando un repositorio local e independiente. Así es como funciona el control de versiones distribuido.
  • Puedes usar diferentes programas de VC de tu equipo. Nuestro equipo usa Subversion, yo uso Mercurial localmente. Los metarchivos de software de 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, esfuerzos de refactorización, etc. y CYAing mientras el equipo continúa FUBAR el código base.

finalizar edición

Lo que estás describiendo es una manera 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 manera, las modificaciones a esa versión pueden ser contenidas y puede seguir ocurriendo más desarrollo.

Este artículo puede darle algunas ideas. Está escrito teniendo en cuenta a git , pero no hay razón para que no pueda funcionar con mercurial también. Me doy cuenta de que no estás usando ninguno de estos, pero ese también es un problema que deberías considerar solucionar.

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

Todas las correcciones de errores se deben hacer en esa rama primero y luego se deben probar y desplegar en otras ramas, para mantener el código sincronizado .

Tu proyecto también debe tener varios entornos for health development como Prod, Staging, QA y Dev (a veces UAT). Estos entornos deben configurarse antes de ir a la versión de producción.

En definitiva, 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:

• Implementando Team Foundation Server con un pequeño equipo de desarrollo
• ¡Bienvenido a la plataforma de integración TFS!
• Guía de desarrollo de equipos con TFS
• Configuración de un entorno de desarrollo

No, porque mientras usa 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, usted ESTÁ PLANEANDO en registrar algunas diferencias, pero en este momento la mayoría de sus cambios no están registrados.

Como han dicho otros, deberías usar ramas. Una vez que tenga esa configuración, debería estar revisando todos los cambios funcionales (es decir, no cada pulsación de tecla, pero cada vez que corrija un error, agregue una característica, elimine una característica o complete un cambio de tal manera que aún se construya y funcione).

Soy un desarrollador y se nos da un código de sucursal y db diferentes para las correcciones de la versión actual y una diferente para las mejoras y para la versión consecutiva posterior.

Una vez que nuestras correcciones están listas, se combinan con la producción y se implementan, obtenemos una nueva sucursal para que vuelva a funcionar con las mejoras.

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

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"

Del mismo modo para otras correcciones, solo hago esto para cada línea que cambio o añado para corregir. Y solo comparar y cometer. 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+F comando y escriba //Start Iteration 2, Fix No-1, Branch No-"ABC" buscar en una 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.