Estrategias para el diseño de repositorio de proyectos multiplataforma

Question

Estoy buscando estrategias con respecto al diseño/diseño del repositorio cuando se trata de proyectos multiplataforma. Por lo general, las dependencias son:

• Proyecto tiene un solo nombre/marca
• Cada plataforma tiene el código fuente separada
• la plataforma de código comparte recursos comunes
• documentos de diseño y demás documentación se comparte entre plataformas

Ya lo he intentado (usando git) a continuación:

Solución A:

• Cada proyecto de plataforma reside en su propio directorio
• commits van a master para todas las plataformas

Ventajas:

• desarrollo de código limpio
• sin fusionar

Desventajas:

• registro es un desastre, que en general tienen como prefijo para todos los registros se comprometen con la plataforma
• veces revertir una confirmación es ..no es posible o muy difícil/complicado

Solución B:

• Cada plataforma tiene su propio rama
• Cuando la liberación de un rebase se realiza en cada rama, y ​​luego fusionar a master + etiqueta

Ventajas:

• troncos limpios :)
• separación limpia para el desarrollo pogress
• menos conflictos

Desventajas:

• necesidad de fusionar a master
• Cuando todas las plataformas de rebase en al mismo tiempo - fusionar al maestro es HELL

estoy indeciso para crear repositorio per-plataforma que compartir recursos podrían ser difíciles o requerirían adicional, posiblemente propenso a errores, tareas.

Esperamos su experiencia chicos.

Answer 1

Esto parece ser un problema de ampliación. Un repositorio normalmente contiene un solo proyecto. Varias partes de un proyecto pueden compartir un módulo de utilidad, pero para proyectos pequeños, la escala no es lo suficientemente grande como para considerar separar el módulo de utilidad como su propia entidad. Sin embargo, una vez que el módulo de utilidad se vuelve "grande" o si varias entidades independientes que lo comparten deben separarse, debe convertirse en su propio módulo (versionado).

Mi enfoque sería utilizar repositorios separados, dependiendo de la cantidad de código. No estoy seguro de lo que quiere decir con tareas adicionales, aunque es un refactor importante. Lo primero que haría sería convertir los recursos compartidos en un repositorio independiente e incorporar lanzamientos de eso como una dependencia (específica de la versión) en cada compilación de la plataforma. Eso desacopla el desarrollo en cada plataforma desde una única versión de recurso compartido. Cada cambio al proyecto compartido requiere probar cada plataforma de todos modos, ahora usted tiene una línea divisoria limpia. Luego puede hacer que cada proyecto tenga su propio depósito de uno en uno.

Si desea tener un "lanzamiento compartido" de un proyecto en múltiples plataformas, necesita un "proyecto" que sea la raíz del código de construcción para eso. También podría considerar usar el repositorio compartido para ese código, pero eso combina las versiones del código compartido con las versiones del proyecto. Lo que probablemente desee, si su código ha alcanzado este nivel de complejidad, es otro repositorio solo para el "metaproyecto" que alberga su código de compilación. A menos que tenga un gran grupo de proyectos con los que trabajar, las versiones para múltiples proyectos podrían residir en un solo repositorio, lo que les permitiría compartir código común. El mismo problema nuevamente, pero con la pequeña escala, funciona un único repositorio. Tenga en cuenta que todo esto supone cierto nivel de pruebas automatizadas :)

Mi experiencia con proyectos de varios módulos proviene del uso de perl y java. En Perl, el uso de muchos módulos compartidos independientes del CPAN es la norma.En Java, las dependencias modulares se pueden manejar usando Apache Ivy o Maven. Usé Maven en un entorno que tenía un metaproyecto de nivel superior para la empresa y proyectos separados para cada producto (que dependía del metaproyecto de la empresa). Cada proyecto era libre de hacer lo que necesitaba. El código escalado de un proyecto para ser compartido entre dos o más proyectos se convertiría en un proyecto propio. Un proyecto particularmente grande finalmente se dividió en varios proyectos que heredaron de su propio "metaproyecto". Manejar este tipo de dependencia jerárquica es lo que Maven e Ivy están diseñados para hacer. Usamos Jenkins/Hudson como un servidor de integración que verificaba las compilaciones de proyectos cruzados cada noche automáticamente (suponiendo que nadie eludiera las pruebas de escritura ...). Una vez que necesitábamos cambiar el sitio web para toda la compañía. ¡No hay problema, lo cambió una vez en el metaproyecto de la empresa y se recogió automáticamente en la nueva versión de cada proyecto!

Answer 2

Posiblemente otra solución:

separada en tres (o más) repositorios:

platform1 specific 
platform2 specific 
common for all platforms 

A continuación, puede añadir el repositorio común en los otros repositorios a través submodules.

Además, Google abordó un problema similar en el repositorio de Android mediante el desarrollo de una herramienta personalizada: repo. Repo utiliza un repositorio de git personalizado (manifiesto) que contiene un archivo XML (manifest.xml o default.xml, ver dentro de .repo/manifiestos) que enumera qué repositorios de Git se deben extraer. De esta forma, también podría crear tres repositorios como el anterior y otro que contenga el archivo XML para usarlos juntos, o incluso crear ramas para cada plataforma en este manifiesto git.

Aunque debo advertir que el repositorio es muy Gerrit centrado.