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

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.

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.

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

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.
   • Control de versiones, mejor explicado

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

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.

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:

• Implementación de Team Foundation Server con un pequeño equipo de desarrollo
• ¡Bienvenido a la plataforma de integración TFS!
• Desarrollo de equipo con guía TFS
• Establecer un entorno de desarrollo

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

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.