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.
Respuestas:
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.
fuente
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 ...
... ¡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í )
fuente
editar
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
fuente
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 funcionemercurialtan 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.fuente
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:
fuente
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).
fuente
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
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
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.fuente