que - Jenkins: ¿Cómo construir múltiples proyectos de alto nivel desde un repositorio de git?

github tutorial español (3)

@recampbell, tengo el mismo problema. Tenemos varios proyectos interrelacionados en un solo repositorio de Hg.

De esa manera, sabemos exactamente bajo qué versión (número de versión hg), se compilan entre sí. Cuando digo exactamente, quiero decir que puedo verificar que es binario idéntico.

El uso de números de versión es demasiado grueso. Por ejemplo, hoy encontré un error que solo era reproducible en hg versión 3367 pero no en hg versión 3368. Usando múltiples repositorios de hg que no hubieran podido reproducirse, ya que hay varios confirmaciones en cada uno de los proyectos todos los días, y por lo tanto es imposible determinar exactamente qué versión de cada proyecto individual se usó, solo la versión hg es la correcta de usar (usando bisect para encontrar el error).

Resultó que cambiamos la versión del controlador de la base de datos del cliente en uno de los subproyectos y eso hizo que nuestra generación automática de dao fallara con un NPE. El controlador, por supuesto, si es una versión de lanzamiento que no escribimos, simplemente usamos el proporcionado por el proveedor. Nos habría llevado varios días depurar esto, pero como usamos Jenkins para construir cada hora, sabíamos que había entre 10 y 20 intentos de búsqueda, y solo 3 o 4 tocaban el dao-generator, por lo que fue una tarea fácil.

Tener versiones mixtas de cada proyecto hubiera sido un dolor en la parte trasera inferior, ya que tendríamos varios dao-generator-3.1.2.jar diferentes que serían un poco diferentes entre sí (a menos que espere que cambiemos) los números de versión después de cada confirmación, o si hay alguna configuración en Jenkins / maven / lo que sea que haga esto automáticamente, sería genial ...).

Tengo un repositorio de Git que contiene un montón de proyectos de alto nivel (cada uno se encuentra en su propio subdirectorio con un pom.xml). El nivel superior aquí significa que estos proyectos se ubican en un subdirectorio directamente debajo de la raíz del repositorio. Todos estos proyectos deben permanecer en el mismo repositorio Git.

repo +--- projectA +--- pom.xml +--- projectB +--- pom.xml

Pueden / deben ser construidos por trabajos de jenkins independientes. Así que tenemos un trabajo para el proyecto A y uno para el proyecto B.

Anteriormente, con Subversion, pude configurar un trabajo de Jenkins (para cada proyecto) que verificaba solo la fuente del proyecto y ejecutaba una compilación de Maven desde el pom.xml.

Con el modelo Git (probablemente lo mismo con todos los DVCS) esto cambia y no estoy seguro de cuál es la mejor práctica. Hay algunas opciones que veo y de las cuales ninguna me gusta mucho:

Cada trabajo de Jenkins está configured para clonar / extraer el repositorio completo de Git y se refiere al /pom.xml para la compilación de Maven. Así que el trabajo tiene todo el código, pero crea solo una parte de él.
Git ofrece submódulos ( http://book.git-scm.com/5_submodules.html ) que parecen ser un poco difíciles de manejar (y pueden romperse fácilmente)
Cree un proyecto principal (agregador que contenga todos los proyectos) que active cada compilación de proyectos (con un solo trabajo de jenkins). Este pom.xml contiene elementos para projectA y projectB.

¿Ves algún enfoque más útil para esto (configuración muy típica)? ¿Cuál es tu experiencia? ¿Alguna de las mejores prácticas?

Bueno, existe la mejor práctica de no repetirse. Así que tener un súper POM sería bueno desde ese punto de vista.

La identificación probablemente vaya con la opción 1. El espacio de disco es generalmente barato.

Pero 3 facilitaría la implementación en nuevos sistemas, sin configurar Jenkins nuevamente.

Creo que estás trabajando contra el grano aquí. Si estos proyectos se lanzan como una unidad versionada, debe crear un POM principal. Pero probablemente deberías tener solo un trabajo de CI. Si desea que la compilación se ejecute rápidamente, puede configurarlo para que solo compile los módulos que han cambiado desde la última compilación (botón avanzado en la sección de compilación - "Compilación incremental, solo compilación de módulos modificados"). También puede decirle a Jenkins que "Ejecute compilaciones concurrentes si es necesario" para probar múltiples confirmaciones a la vez.

Pero tengo curiosidad por qué crees que quieres múltiples trabajos de CI? Si percibe que estos dos proyectos tienen ciclos de vida diferentes, tal vez deberían ser versionados por separado y, por lo tanto, deberían estar en repositorios git separados. No conserves los repositorios de git, son baratos. De hecho, cuanto más mejor en casi todos los casos.

Por lo general, usted quiere que un pom dado produzca un único artefacto. Los poms agregadores son útiles para dividir partes de un artefacto más grande en submódulos, pero solo si esos submódulos no se lanzan solos.