Trabajo en una pequeña tienda donde tenemos MUCHO código de Cobol heredado y donde se ha adoptado una metodología que nos permite minimizar la bifurcación y ramificación tanto como sea posible.¿Una metodología que permite una única base de código Java que cubre muchas versiones diferentes?
Dado un release tenemos tres niveles:
- CORE - capa inferior, este código es común a todas las versiones
- GRUPO - código opcional comunes a varios clientes.
- CLIENTE: código opcional específico para un solo cliente.
Cuando se necesita un programa, primero se busca en CUSTOMER, luego en GROUP y finalmente en CORE. Una aplicación determinada para nosotros invoca muchos programas que todos se buscan en esta secuencia (piense en archivos exe y PATH en Windows).
También tenemos programas Java que interactúan con este código heredado, y como el mehchanism de búsqueda de core-group-customer no se presta fácilmente a Java, ha crecido en una rama CVS para cada cliente, requiriendo mucho mantenimiento. La parte de Java y la parte de back-end tienden a desarrollarse en paralelo.
Me han asignado una forma de hacer que los dos mundos se encuentren.
Básicamente queremos un entorno Java que nos permita tener una única base de código con fuentes para cada versión, donde podemos seleccionar fácilmente un grupo y un cliente y trabajar con la aplicación como lo hace para ese cliente, y luego fácilmente cambiar a otro conjunto de códigos y ESE cliente.
Estaba pensando en quizás un escenario con un proyecto de Eclipse para cada núcleo, cliente y grupo y luego usar conjuntos de proyectos para seleccionar los que necesitamos para un escenario determinado. El problema que no entiendo es cómo crearíamos un código sólido en los proyectos CORE que funcionará independientemente de qué grupo y cliente se seleccione. ¿Una clase Factory que sabe qué subclase de un objeto Class pasado invocar en lugar de cada nuevo?
Otros deben tener problemas de administración de bases de código similares. ¿Alguien con experiencias para compartir?
EDIT: La conclusión de este problema anterior ha sido que CVS tiene que ser reemplazado con un sistema de gestión de código fuente más adecuada para tratar con muchas ramas al mismo tiempo y la migración de la fuente de un componente a otro mientras se mantiene historia. Inspirados por la migración reciente de slf4j y logback, actualmente estamos analizando git porque maneja muy bien las ramas. También hemos considerado subversión y mercurial, pero git parece ser mejor para proyectos multirradenados de ubicación única. He preguntado sobre Perforce en otra pregunta, pero mi inclinación personal es hacia las soluciones de código abierto para algo tan crucial como este.
EDIT: Después de un poco más de ponderación, hemos encontrado que nuestro punto de dolor real es que utilizamos ramas en el CVS, y que se ramifica en CVS son los más fáciles de trabajar si se ramifican todos los archivos! La conclusión revisada es que puede hacer esto solo con CVS, al cambiar a un bosque de proyectos Java, cada uno correspondiente a uno de los niveles anteriores, y usar las rutas de construcción de Eclipse para unirlas para que cada versión del CLIENTE muestre el apropiado GRUPO y proyecto CORE. Todavía queremos cambiar a un mejor sistema de control de versiones, pero esta es una decisión tan importante, por lo que queremos retrasarla tanto como sea posible.
EDIT: Ahora tengo una aplicación de prueba de concepto del concepto de grupo central en el cliente a través de Google Guice 2.0 - la etiqueta @ImplementedBy es justo lo que necesitamos. Me pregunto qué hacen todos los demás? ¿Usar if's por todo el lugar?
EDITAR: Ahora también necesito esta funcionalidad para aplicaciones web. Guice fue hasta que el JSR-330 está en su lugar. ¿Alguien con experiencia en el control de versiones?
EDIT: JSR-330/299 se encuentra ahora en su lugar con la implementación de referencia JEE6 Weld basado en JBoss Seam y me han reimplantado la prueba de concepto con autógena y se puede ver que si utilizamos a lo largo de @Alternative con ... en beans.xml podemos obtener el comportamiento que deseamos. Es decir. proporcione una nueva implementación para una funcionalidad dada en CORE sin cambiar un poco en los frascos CORE. La lectura inicial en la especificación de Servlet 3.0 indica que puede admitir la misma funcionalidad para la aplicación web recursos (no código). Ahora haremos una prueba inicial en la aplicación real.
+1 para que esto no sea mi problema. :) – cletus
Cletus, heh, ¿así que acabo de enumerar todos los trabajos asignados a mí, y el karma instantáneo de 100k? –
Si son tan asquerosos y horripilantes como este trabajo, claro. :) – cletus