2009-08-02 11 views
12

He estado buscando en buildbot últimamente, y la falta de buena documentación y configuraciones de muestra hace difícil comprender cómo se usa comúnmente buildbot.Cómo escalar buildbot en una compañía

De acuerdo con el manual de buildbot, cada buildmaster es responsable de 1 base de código. Eso significa que una empresa que quiere usar buildbot en, digamos, 10 proyectos, necesita mantener 10 conjuntos diferentes de instalaciones de buildbot (configuraciones maestro-esclavo, puertos abiertos, sitios web con salida, etc.). ¿Es esta la manera en que se hacen las cosas? ¿Me estoy perdiendo una opción que crea un mash-up que es fácil de mantener y monitorear?

Gracias!

+1

FWIW, actualmente hay trabajos en curso para mejorar la escala de buildbot, patrocinado por el proyecto Mozilla. (¿Quién ejecuta un buildmaster muy grande?) Consulte la lista de correo buildbot para más detalles. – Macke

Respuesta

4

En mi lugar de trabajo utilizamos Buildbot para probar un solo programa en varias arquitecturas y versiones de Python. Yo uso un maestro de construcción para supervisar alrededor de 16 esclavos. Cada conjunto de esclavos extrae de un repositorio diferente y lo prueba contra Python 2.X.

Desde mi experiencia, sería fácil configurar un maestro de construcción único para ejecutar una combinación de proyectos. Puede que esta no sea una buena idea porque la página de la cascada (donde los esclavos de la construcción informan los resultados) puede estar muy congestionada con más de unos pocos esclavos. Si te sientes cómodo desplazándote por una página de cascada larga, entonces esto no será un problema.

EDIT:

El comando de actualización en master.cfg:

test_python26_linux.addStep(ShellCommand, name = "update pygr", 
    command = ["/u/opierce/PygrBuildBot/update.sh","000-buildbot","ctb"], workdir=".") 

000-buildbot y CTB son parámetros adicionales para especificar qué rama y cesión temporal para tirar de obtener la información. El script update.sh es algo que escribí para evitar un problema de git no relacionado. Si desea ejecutar proyectos diferentes, puede escribir algo como:

builder1.addStep(ShellCommand, name = "update project 1", 
    command = ["git","pull","git://github.com/your_id/project1.git"], workdir=".") 

(the rest of builder1 steps) 

builder2.addStep(ShellCommand, name = "update project 2", 
    command = ["git","pull","git://github.com/your_id/project2.git"], workdir=".") 

(the rest of builder2 steps) 

Los dos proyectos no tienen que estar relacionados. Buildbot crea un directorio para cada constructor y ejecuta todos los pasos en ese directorio.

+0

La configuración maestra simplemente le dice al esclavo que ejecute una serie de comandos de terminal. Para ejecutar una versión diferente o un proyecto diferente, simplemente dígale que saque de un repositorio diferente. Como puede individualizar los comandos para cada esclavo, puede hacer que cada esclavo ejecute una versión/proyecto/lo que sea diferente. –

+0

No, eso es lo contrario de lo que estoy diciendo. Extraer de un repositorio y ejecutar compilaciones en tiempo real es la idea detrás de la integración continua. Usamos git para control de versiones. –

+0

Finalmente entendí lo que quieres decir con esto, y esta es realmente una buena idea. Solo vale la pena dar una nota: decidimos usar categorías, de modo que ahora podemos dividir la vista de la cascada de acuerdo con esas categorías, por lo que cada desarrollador solo ve los proyectos que le interesan. – abyx

3

FYI, BuildBot 0.8.x es compatible con varios repositorios en un maestro, lo que simplifica un poco las cosas.

+1

Puede ver un ejemplo en una [pregunta relacionada] (http://stackoverflow.com/questions/2795386/support-for- multiple-repositories-using-buildbot/7148534 # 7148534) – hithwen

Cuestiones relacionadas