2009-01-08 14 views

Respuesta

27

He probado esta característica hace algunos meses, pero ya no la uso (solo porque no la necesito, no porque no sea una buena característica).

Básicamente, usted define n Eje, cada eje es una propiedad con varios valores.

Veamos un ejemplo: define el eje "JDK", con el posible valor "1.4", "1.5", "1.6", y define otra propiedad "base de datos", donde los posibles valores son "oráculo", "mysql".

Por lo tanto, Hudson lanzará su construcción: 6 veces

  • con JDK 1.4, con la base de datos Oracle propiedad = (es decir, la JVM se puso en marcha con -Ddatabase = oráculo)
  • con JDK 1.5, con la base de datos propiedad = oráculo
  • con JDK 1.6, con la base de datos propiedad = oráculo
  • con JDK 1.4, con la base de datos propiedad = mysql
  • con JDK 1.5, con la base de datos propiedad = mysql
  • con JDK 1.6, con la base de datos MySQL propiedad =

Entonces, una vez que todo ha terminado, usted será capaz de ver los resultados de cada iteración.

Esta función puede ser muy útil cuando necesite probar su aplicación en varios entornos (en mi ejemplo, con diferentes versiones de JDK o base de datos).

Tenga en cuenta que, a excepción del eje JDK, debe gestionar usted mismo la propiedad dada como entrada por Hudson. En mi ejemplo, la aplicación debe tener en cuenta la propiedad "base de datos". Eventualmente, una buena idea es usar esta propiedad para habilitar un perfil particular en la configuración de Maven2, si el proyecto está mavenizado (ver here para obtener más detalles al respecto).

espero que mis explicaciones son claras suficiente :)

+2

¿Cómo accedes a estas propiedades para proyectos que no son de Java? Como variables de entorno? –

+2

@Sridhar Normalmente sí, estas propiedades las establece Hudson como variables de entorno para la compilación actual. – romaintaz

+2

OK, esta pregunta ha expirado hace tiempo, pero tengo dificultades para configurar un proyecto de matriz, ¿algún consejo sobre cómo configurar uno? :) –

6

Matrix construye una serie de cuestiones:

  • En términos incompatibles con plugins - que son cada vez mejores, pero hay que estar manteniendo mucho hasta hasta la fecha.
  • Artefactos: mucho más difícil de escabullir - Los URls son un poco más incómodos, encontrarlos en el FS (que de todos modos deberías evitar) es ahora una pesadilla.

Lo cual es una pena, porque el concepto es muy bueno y muy útil donde funciona.


Editar

  • imposibilidad de iniciar puntos individuales.

Nuestra forma habitual de resolver esto es tener las compilaciones parametrizadas configuradas para ejecutarse de forma simultánea, lo que trae sus propios problemas, pero nos ahorra tener muchos trabajos con el mismo código y diferentes constantes.

+0

¿Tiene una mejor sugerencia? Estoy buscando usar una construcción matricial para dividir nuestra suite unittest en una cantidad de trabajos idénticos que cada uno ejecute un subconjunto diferente de la suite (para acelerar nuestro ciclo de prueba de nuestros 40 minutos actuales a <5 minutos) – PerilousApricot

+0

Usamos código en los pasos de compilación para iniciar trabajos parametrizados, por lo que un trabajo principal "kicker" o "scheduler" inicia los trabajos posteriores. Usamos un parámetro de causa para vincularlos una copia de seguridad y parámetros de guía para encontrar los trabajos una vez fuera de la cola para que el trabajo principal pueda mostrar todos los trabajos secundarios que inició. Esto fue: un solo trabajo está parametrizado, y las herramientas padre + otras de creación de vistas se pueden usar para verlas. Usamos la función permitir carreras concurrentes también. –

Cuestiones relacionadas