Pregunta "Mejor práctica" de control de versiones


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

El escenario es:

tenemos una aplicación web de tamaño medio / grande que tiene (al menos debería tener) un núcleo que se implementa para 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 sucursales, usamos etiquetas para diferenciar los cambios de código en la aplicación (sí, sé que es bastante malo). Esto trae muchos problemas cuando queremos hacer un lanzamiento a un cliente específico, cambios en el registro de entrada, etc ... Para preparar un lanzamiento, siempre toma alrededor de 1 a 2 días de trabajo y, a veces, aún se interrumpe.

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

Entonces 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 derivar 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 sucursales son "temporales", tengo dudas si la bifurcación es la mejor solución.

Gracias por la respuesta.

Antonio Dias


5
2017-09-07 16:33


origen


Respuestas:


No sé por qué crees que las ramas son temporales; existirán todo el tiempo que quieras.

Su aplicación suena como si pudiera beneficiarse de la reestructuración para implementar una funcionalidad más modular, pero mientras tanto, puede desarrollar la funcionalidad principal como troncal, con cada versión del cliente convirtiéndose en su propia sucursal.

Las modificaciones al 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.


4
2017-09-07 16:52



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 como la describe (cada cliente requiere cambios de gran alcance en el núcleo), es posible que desee explorar si el uso de directivas de compilación para aislar los cambios individuales del cliente funciona mejor para usted que la ramificación. El problema con la ramificación (como estoy seguro de que descubrió) es que una solución colocada en una rama a menudo debe propagarse a todas las demás (ya que nunca tendrá la intención de fusionar las sucursales 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 esta estrategia de ramificación por cliente a medida que agrega nuevos clientes.


4
2017-09-07 16:56



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:  - tronco es el desarrollo principal del proyecto, es donde todos los miembros del equipo cooperan  - la sucursal es el lugar para el desarrollo temporal (sí, lo oíste bien). Aquí es donde puede hacer experimentos o alterar el código sin afectar a otros miembros del equipo.  - la etiqueta no es más que "snapshot con nombre". En las instantáneas del proyecto de control de versiones están en todas partes, la etiqueta es la forma en que puede darles un nombre más legible Si intentas obtener más y más sucursales sin disponer de ellas, tu proyecto crecerá y crecerá para siempre. Todavía me pregunto por qué tienes que hacer un seguimiento de todos esos de todos modos. Permítanme repetir una vez más, el control de versiones es solo para cooperar con el código fuente, no para distribuir a múltiples clientes. Espero que ayudes


3
2017-09-07 16:59



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 - via Martin Fowler

El control de versiones no es la herramienta adecuada para esto, ya que desea usarlo para administrar versiones, no clientes.


2
2017-09-07 17:07



En primer lugar, abra sucursales y aprenda a usar su sistema de control de versiones correctamente.

Trabajé en un proyecto en el que intentaron administrar las versiones de la forma que describiste, a través de etiquetas. Era tarea de alguien agregar / fusionar cambios manualmente en una etiqueta y luego aplicar una nueva etiqueta. Esto hace que sea muy difícil para todos permanecer sincronizados y casi siempre lleva a compilaciones dañadas debido a errores simples (archivos olvidados, pisando cambios, etc.). Básicamente estás haciendo manualmente lo que las ramas hacen por ti..

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

¿Es posible dividir componentes y tener subproyectos? Es posible que algunas de las áreas centrales no cambien con frecuencia y se puedan agregar a la compilación (algo así como frascos de terceros).

O puede tener su versión básica de compilación / instalación y luego colocar las personalizaciones en capas. Superponer los archivos personalizados y / o modificar los archivos base.


1
2017-09-07 17:06



Sucursales se hacen para aislar un "esfuerzo de desarrollo" (aquí alguna personalización) que no se puede hacer en las mismas sucursales actuales.
Como las etiquetas están destinadas a hacer referencia a un contenido "inmutable", no debes hacer ninguna evolución en él. Un simple:

 cvs tag -r MY_TAG -b MY_BRANCH

sería suficiente para inicializar una rama desde una etiqueta de rama.

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

  • intente fusionar el contenido de una rama anterior hecha para una demostración anterior para un cliente en esta nueva rama
  • o directamente reimplementar las personalizaciones en la nueva rama.
  • dejar esas ramas como están cuando se realiza el ciclo UAT. No se modificarán, pero pueden servir como referencia para las siguientes ramas para el próximo ciclo.

Tratar de mantener una rama con personalización sería más difícil que recrear dichas evoluciones en una nueva rama: eso requeriría fusionar el desarrollo actual en esa rama de larga duración, y es muy posible que su desarrollo introduzca cambios mucho más complejos en el código que las evoluciones que hizo para la demostración del cliente.


0
2017-09-07 16:54