build - Herencia de trabajo en trabajos de Jenkins
continuous-integration quickbuild (4)
¿Cómo maneja la asignación de trabajos de Jenkins a su proceso de compilación y ha podido construir configuraciones en cascada en la herencia?
Para cualquier compilación dada tendré al menos tres trabajos (integración continua estándar / noche, análisis de seguridad, cobertura) y luego algunos trabajos de prueba de integración descendente. El complemento de la segmentación de la configuración maneja algunos aspectos de los trabajos cruzados, pero cada trabajo sigue siendo en gran medida su propia entidad individual sin relación con los otros trabajos de su grupo.
Recientemente vi QuickBuild y tiene una herencia de trabajo en la que los trabajos principales pueden definir un grupo estándar de pasos y sus secundarios pueden anular y especializarse. Con Jenkins, tengo copias de trabajos, lo cual está bien hasta que necesito cambiar algo. Con QuickBuild, la relación entre los trabajos me permite difundir mis cambios con poco esfuerzo.
He estado tratando de averiguar cómo manejar esto en Jenkins. Podría usar el complemento desencadenante de creación parametrizado para permitir que los trabajos llamen a otros y anulen aspectos. Luego cosecharía los datos de los trabajos a los que llamaba. Sospecho que me encontraré con una serie de problemas en los que hay aspectos que no puedo anular, lo que me obligará a implementar la funcionalidad de Jenkins en mi propio script, lo que hace que sea menos útil.
¿Cómo manejas la complejidad en tus trabajos de construcción en Jenkins? ¿Has oído hablar de algún problema grave con QuickBuild?
Me gustaría señalarles el lanzamiento de un complemento que mi equipo ha desarrollado y que acaba de publicar recientemente en código abierto. Implementa plena "Herencia entre trabajos".
Aquí para otros enlaces que pueden ayudarle:
Me preguntaron cuál era nuestra solución final al problema ... Después de muchos meses de pelear con nuestro sistema de compras, gastamos alrededor de $ 4000 en Quickbuild. En alrededor de 2 o 3 meses tuvimos un sistema de construcción con plantilla y nos sentimos muy felices con él. Antes de dejar la empresa, teníamos varios grupos de productos en el sistema y también estábamos automatizando el proceso de lanzamiento.
Quickbuild fue un gran producto. Debería estar en la clase de $ 40k, pero su precio es mucho menor. Si bien estoy seguro de que Jenkins podría hacer esto, sería un poco de un kludge mientras que Quickbuild tenía esta funcionalidad incorporada. He implementado comportamientos complejos en la parte superior de los productos anteriormente (por ejemplo, el seguimiento de mezcla en SVN 1.0) y lo lamenté. Quickbuild tenía un precio razonable y proporcionaba una base sólida para nuestros sistemas de compilación y prueba.
En la actualidad, estoy en una empresa que utiliza Bamboo y espero que su nueva función de rama de características proporcione mucho de lo que Quickbuild puede hacer.
Tuve casi el mismo problema Tenemos un conjunto de trabajos que deben ejecutarse para nuestro tronco, así como al menos dos sucursales. Las sucursales representan nuestras versiones y se crea una nueva sucursal cada pocos meses. Crear nuevos trabajos a mano para esto no es una solución, así que revisé algunas posibilidades.
Una posibilidad es usar el plugin de plantilla . Esto le permite crear una jerarquía de trabajos de un tipo. Proporciona herencia para constructores, editores y configuraciones de SCM. Podría funcionar para algunos, para mí no fue suficiente.
Lo segundo que revisé fue el Ant Script para la clonación de trabajos y su hermano el Bash Script . Estos son realmente grandes. La idea es hacer que el script cree un nuevo trabajo para, copiar todas las configuraciones de un trabajo de plantilla, realizar cambios a medida que los necesite. Como este es un script, es muy flexible y puedes hacer mucho con eso. El único inconveniente es que esto no dará lugar a una jerarquía real, por lo que los cambios en el trabajo de la plantilla no se reflejarán en los trabajos ya clonados, solo en los trabajos que se crearán en el futuro.
Al observar los inconvenientes y las virtudes de estas dos soluciones, una combinación de ambas podría funcionar mejor. Crea un proyecto de plantilla con algunas configuraciones básicas que serán verdaderas para todos los trabajos, y luego usa un script bash o ant para crear trabajos dependiendo de esa plantilla.
Espero que ayude.
Utilizamos quickbuild y parece funcionar muy bien para la mayoría de las cosas. Incluso he podido usar sus API para escribir complementos personalizados. Un área donde falta la construcción rápida es la integración de sonar. El equipo de sonar tiene un complemento de Jenkins y no uno para quickbuild.