Acelerando el servidor de compilación de integración continua de PHP en Hudson CI

Question

Estoy tratando de acelerar mis compilaciones y estaba buscando algunas ideas sobre cómo hacerlo. Actualmente uso Hudson como servidor de integración continua para un proyecto PHP.

Utilizo un archivo Ant build.xml para hacer la construcción, usando un archivo similar al de Sebastian Bergmann php-hudson-template. Por el momento, sin embargo (debido a algunos problemas extraños con Hudson se bloquea de lo contrario), solo estoy ejecutando phpDocumentor, phpcpd y phpUnit. phpUnit genera Clover informes de cobertura de código, también.

Éstos son algunos cuellos de botella posibles:

1. phpDocumentor: Toma 180 segundos. Hay algunas bibliotecas grandes incluidas en mi proyecto, como awsninja, DirectedEdge, oauthsimple y phpMailer. No estoy seguro de que realmente necesite desarrollar documentación para estos. Tampoco estoy seguro de cómo ignorar subdirectorios enteros utilizando mi archivo build.xml.
2. phpUnit: Tarda 120 segundos. Esta es la única parte de la compilación que no se ejecuta como parallelTask. Cuantas más pruebas se escriban, más tiempo aumentará. Realmente no estoy seguro de qué hacer al respecto, aparte de quizás ejecutar múltiples esclavos de compilación de Hudson y repartir suites de prueba separadas para cada esclavo. Pero tampoco tengo idea de cómo hacerlo.
3. phpcpd: Tarda 97 segundos. Estoy seguro de que puedo eliminar algunos análisis y tiempo de conversión ignorando esas bibliotecas incluidas. No estoy seguro de cómo hacer esto en mi archivo build.xml.
4. Mi servidor: En este momento estoy usando un único servidor Linode. Parece estar bastante sujeto a impuestos por todo el proceso.

Cualquier otro posible cuello de botella que pueda pensar lo agregaré a la lista.

¿Cuáles son algunas soluciones para reducir mi tiempo de construcción?

Answer 1

No soy un experto en PHP en absoluto, pero debería ser capaz de dividir sus pruebas de PHPUnit en múltiples esclavos Hudson si es necesario. Simplemente dividiría su suite de pruebas y ejecutaría cada subconjunto como un trabajo paralelo y paralelo de Hudson. Si tiene una máquina con varias CPU/núcleos, puede ejecutar múltiples esclavos en ella.

Una cosa obvia que no mencionó: ¿qué hay de simplemente actualizar su hardware, o echar un vistazo a qué más se está ejecutando en el host Hudson y posiblemente tomar recursos?

Answer 2

1. phpDocumenter: phpdoc -h revela la opción -i, que le permite especificar una lista separada por comas de archivos/directorios a ignorar separado. Esto se puede agregar a la etiqueta arguments de su etiqueta phpdoc build.xml

2. phpUnit: Noté que puede ser lento si estoy ejecutando pruebas en una base de datos, pero no estoy al tanto de cómo mejorar esto.

Una cosa posible que podría ayudar sería la de no correr documentador cada vez y sólo se ejecutan como parte de un edifico que sólo ocurre una vez al día (o algo similar)

Hace poco empecé a usar estas herramientas y estas son pocas cosas que descubrí.

Answer 3

Cuando tuvimos un problema similar, recurrimos a ejecutar la documentación en una compilación de una noche separada (junto con nuestras secuencias de comandos de prueba funcional en Selenium, ya que esto también es bastante lento). De esta forma, nuestra compilación principal de CI no se desaceleró al generar nuestra documentación API.

Sin embargo, observo que PHP Documentor ahora se ha actualizado a la versión 2, que tiene mejoras de velocidad significativas en comparación con la versión anterior 1. Parece que está en la región de dos a tres veces más rápido que v1. Esto hará una gran diferencia en su proceso de CI. Vea http://phpdoc.org/ para más información.

Como alternativa, puede echar un vistazo a apiGen y phpDox, que son alternativas a PHPDoc. Ambos son definitivamente más rápidos que PHPDoc v1; Todavía no los he comparado con v2.