Sistema de Integración Continua para una Base de código Python

Una posibilidad es Hudson. Está escrito en Java, pero hay integración con proyectos Python:

Hudson abraza a Python

Yo nunca lo he probado, sin embargo.

(Update , Sept. 2011: Después de una disputa de marca, Hudson ha sido renombrado a Jenkins .)

Segundo la integración Buildbot - Trac. Puede encontrar más información sobre la integración en el sitio web Buildbot. En mi trabajo anterior, escribimos y usamos el plugin que mencionan (tracbb). Lo que hace el plugin es reescribir todas las URL de Buildbot para que puedas usar Buildbot desde Trac. ( http://example.com/tracbb).

Lo realmente bueno de Buildbot es que la configuración está escrita en Python. Puede integrar su propio código Python directamente en el configuración. También es muy fácil escribir tus propios BuildSteps para ejecutar tareas específicas.

Usamos BuildSteps para obtener el código fuente de SVN, extraer las dependencias, publicar los resultados de las pruebas en WebDAV, etc.

Escribí una interfaz X10 para que pudiéramos enviar señales con los resultados de compilación. Cuando la construcción falló, encendimos una lámpara de lava roja. Cuando la construcción tuvo éxito, una lámpara de lava verde se encendió. Buenos tiempos :-)

Usamos Buildbot y Hudson para el desarrollo de Jython. Ambos son útiles, pero tienen diferentes fortalezas y debilidades.

La configuración de Buildbot es pura de Python y bastante simple una vez que te acostumbras (mira los documentos de la API generados por epydoc para obtener la información más reciente). Buildbot hace que sea más fácil definir tareas que no sean de prueba y distribuir los probadores. Sin embargo, realmente no tiene ningún concepto de pruebas individuales, solo textual, HTML y salida de resumen, por lo que si desea tener salida de prueba navegable de varios niveles y así sucesivamente tendrá que construirlo usted mismo, o simplemente usar Hudson.

Hudson tiene un excelente soporte para explorar los resultados generales en conjuntos de pruebas y pruebas individuales; también es ideal para comparar la salida de prueba entre compilaciones, pero el material distribuido (maestro / esclavo) es comparativamente más complicado porque también necesita un entorno Java en los esclavos; además, Hudson es menos tolerante con los enlaces de red flaky entre el maestro y esclavo.

Por lo tanto, para obtener los beneficios de ambas herramientas, ejecutamos una sola instancia de Hudson, que captura los fallos de prueba comunes, luego hacemos regresión multiplataforma con Buildbot.

Aquí están nuestras instancias:

• Jython Hudson
• Jython buildbot

Estamos utilizando Bitten que está integrado con trac. Y está basado en Python.

TeamCity tiene alguna integración de Python .

Pero TeamCity es:

• no es de código abierto
• no es pequeño, sino rico en características
• es gratis para equipos pequeños y medianos.

Tengo muy buenas experiencias con Travis-CI para bases de código más pequeñas. Las principales ventajas son:

• la configuración se realiza en menos de la mitad de una pantalla del archivo de configuración
• puede hacer su propia instalación o simplemente usar la versión alojada gratuita
• configuración semiautomática para repositorios github
• no se necesita una cuenta en el sitio web; inicie sesión a través de github

Algunas limitaciones:

• Python no es compatible como un lenguaje de primera clase (a partir del momento de escribiendo; pero puede usar pip y apt-get para instalar dependencias de python; vea este tutorial)

• El código debe estar alojado en github (al menos cuando se utiliza la versión oficial)