"Mejor práctica" de control de versiones

Question

He estado leyendo todas las preguntas aquí sobre el tema del control de versiones, pero no creo haber encontrado un escenario que se parezca al mío.

El escenario es:

tenemos una aplicación de medio/gran tamaño web que tiene (al menos debería tener) un núcleo que se despliega a todos los clientes. Cuando hacemos demostraciones de la aplicación a los clientes, casi todos solicitan cambios en el diseño, los datos en los listados, los campos en los formularios de entrada de datos, etc. Casi todos estos cambios requieren cambios en el resto ". capas "de la aplicación.

En nuestra situación actual estamos usando CVS (con tortoiseCVS) y no usamos ramas, utilizamos etiquetas para diferenciar los cambios de código de la aplicación (sí, sé que es bastante malo). Esto trae muchos problemas cuando queremos hacer un lanzamiento a un cliente específico, y cambios en el check-in, etc. Para preparar un lanzamiento, siempre lleva alrededor de 1-2 días de trabajo y, a veces, aún se rompe.

A veces, una solicitud de un cliente también se incluye en el núcleo para ser distribuida a todos los clientes.

Así que mi pregunta es: ¿son las sucursales la mejor manera de aislar los cambios en las versiones de cliente personalizadas de la aplicación? ¿Deberíamos ramificarnos cada vez que un nuevo cliente solicite personalización? ¿O deberíamos tratarlo como un proyecto completamente diferente, con un repositorio diferente?

Todas las diferentes versiones tendrán que mantenerse, y como he escuchado que las ramas son "temporales", tengo dudas si la bifurcación es la mejor solución.

Gracias por la respuesta.

Antonio Dias

Answer 1

No sé por qué piensa que las ramas son temporales - existirán siempre y cuando se desea.

Su aplicación parece que podría beneficiarse de la reestructuración para implementar más funcionalidades modulares, pero mientras tanto puede desarrollar la funcionalidad principal como la troncal, con cada versión del cliente convirtiéndose en su propia sucursal.

Las modificaciones del código central se pueden fusionar en cada rama según sea necesario. Los cambios específicos del cliente se pueden realizar de forma aislada en esa rama o fusionarse de nuevo en la línea troncal en una fecha posterior.

Los repositorios separados para cada cliente suenan como algo completamente incorrecto, ya que daría lugar a la duplicación del código común entre repositorios.

Answer 2

Branches están hechas para aislar un "esfuerzo de desarrollo" (aquí algunas personalizaciones) que no se puede hacer en las mismas ramas actuales.
Dado que las etiquetas están destinadas a hacer referencia a un contenido "inmutable", no debe hacer ninguna evolución en él. Un simple:

cvs tag -r MY_TAG -b MY_BRANCH 

sería suficiente para inicializar una bifurcación desde una etiqueta de bifurcación.

Esas ramas se deben realizar para cada ciclo de UAT (prueba de aceptación del usuario), comenzando desde su desarrollo actual.A continuación, puede:

• o bien tratar de fusionar el contenido de una rama previo realizado para una demostración previa para un cliente en esta nueva rama
• o directamente volver a aplicar las personalizaciones en la nueva sucursal.
• deja esas ramas como están cuando el ciclo de UAT está hecho. No se modificarán, pero pueden servir como referencia para las siguientes ramas para el próximo ciclo.

Para tratar de mantener una rama con la personalización sería más difícil que re-crear dicho evoluciones en una nueva rama: Para ello sería necesario combinar el desarrollo actual de esa rama de larga vida, y es muy posible que su desarrollo introduce cambios mucho más complejos al código que las evoluciones que hiciste para la demostración del cliente.

Answer 3

En primer lugar, puede que sea mejor que muerda la bala y refactorice su código para reducir el impacto de toda esta personalización. Existen buenos patrones que permiten este tipo de escenario (vienen a la mente los complementos de configuración, los complementos, la fábrica de software).

Dicho esto, si la aplicación es la que usted describe (cada cliente requiere cambios de gran envergadura en el núcleo), puede explorar si el uso de las directivas del compilador para aislar los cambios individuales del cliente funciona mejor para usted que la bifurcación. El problema con la bifurcación (como estoy seguro de que descubriste) es que una solución colocada en una rama a menudo necesita ser propagada a todas las otras ramas (ya que nunca tienes la intención de fusionar las ramas en el futuro). Además, es posible que tenga que corregir la versión de producción que se ejecuta en un cliente, mientras continúa desarrollando en la próxima versión para ese cliente ... una rama de una sucursal.

Las cosas solo empeorarán si continúa con esta estrategia de rama por cliente a medida que agrega nuevos clientes.

Answer 4

Por lo que sé, lo que has estado haciendo no es lo que se supone que debe hacer el control de versiones. Solo se utiliza para realizar un seguimiento de su código fuente, no de su producto distribuido. Para su pregunta sobre las sucursales, creo que esta pequeña explicación puede ayudar: - el tronco es el desarrollo principal del proyecto, aquí es donde todos los miembros del equipo cooperan - la sucursal es el lugar para el desarrollo temporal (sí lo escuchó bien). Aquí es donde puedes hacer experimentos o jugar con el código sin afectar a otros miembros del equipo - la etiqueta no es más que "instantánea con nombre". En las instantáneas del proyecto de control de versiones están en todas partes, la etiqueta es la manera en que puede darles un nombre más legible Si intenta obtener más y más sucursales sin disponer de ellas, su proyecto crecerá y crecerá para siempre. Todavía me pregunto por qué tienes que hacer un seguimiento de todos esos de todos modos. Me repito una vez más, el control de versiones es para cooperar solo en el código fuente, no para distribuirlo a múltiples clientes. Espero que ayude

Answer 5

Antes que nada, abra las sucursales y aprenda a usar su sistema de control de versiones correctamente.

Trabajé en un proyecto donde intentaron administrar versiones de la manera que describió, a través de etiquetas. Era tarea de alguien agregar/fusionar manualmente los cambios a una etiqueta y luego aplicar una nueva etiqueta. Hace que sea muy difícil para todos mantenerse sincronizados y casi siempre conduce a construcciones rotas debido a errores simples (archivos olvidados, pisando fuerte en los cambios, etc.). Básicamente está haciendo manualmente lo que las sucursales hacen por usted.

En cuanto a cómo administrar las personalizaciones divergentes del cliente.Además de administrar una estrategia de bifurcación para cada versión de cliente, debe echar un vistazo a la arquitectura y pensar cómo desea administrar las personalizaciones/diferencias.

¿Es posible separar componentes y tener subproyectos? Algunas de las áreas centrales pueden no cambiar con frecuencia y podrían agregarse a la compilación (algo así como jarras de terceros).

O podría tener su compilación/instalación básica y luego aplicar capas a las personalizaciones. Superponga los archivos personalizados y/o modifique los archivos base.

Answer 6

Feature Branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging. 

--Dan Bodart - a través de Martin Fowler

El control de versiones no es mucho la herramienta adecuada para esto, ya que desea utilizar para gestionar versiones, no los clientes.