tutorial - Sistema de integración continua para una base de código Python

jenkins tutorial pdf español (7)

Estoy empezando a trabajar en un proyecto de pasatiempo con una base de código de Python y me gustaría configurar alguna forma de integración continua (es decir, ejecutar una batería de casos de prueba cada vez que se realiza un check-in y enviar correos electrónicos molestos a los responsables personas cuando las pruebas fallan) similar a CruiseControl o TeamCity .

Me doy cuenta de que podría hacer esto con ganchos en la mayoría de los VCS , pero eso requiere que las pruebas se ejecuten en la misma máquina que el servidor de control de versiones, que no es tan elegante como me gustaría. ¿Alguien tiene alguna sugerencia para un sistema de integración continua de código abierto pequeño, fácil de usar y adecuado para una base de código Python ?

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

Segundo, la integración de 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 complemento que mencionan (tracbb). Lo que hace el complemento es reescribir todas las URL de Buildbot para que pueda 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 de Python directamente a la configuración. También es muy fácil escribir sus propios BuildSteps para ejecutar tareas específicas.

Utilizamos BuildSteps para obtener la fuente de SVN, extraer las dependencias, publicar los resultados de las pruebas en WebDAV, etc.

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

TeamCity tiene alguna integration Python.

Pero TeamCity es:

no de código abierto
no es pequeño, sino más bien rico en funciones
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 media pantalla del archivo de configuración
puedes hacer tu propia instalación o simplemente usar la versión alojada gratis
configuración semiautomática para repositorios github
no se necesita cuenta en el sitio web; iniciar sesión a través de github

Algunas limitaciones

Python no es compatible con un lenguaje de primera clase (al momento de la escritura; pero puede usar pip y apt-get para instalar dependencias de python; consulte este tutorial )
el código debe estar alojado en github (al menos cuando se usa la versión oficial)

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

Hudson abraza a Python

Sin embargo, nunca lo he probado.

( Actualización , septiembre de 2011: después de una disputa de marca registrada, se cambió el nombre de Hudson a Jenkins ).

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

La configuración de Buildbot es Python puro y bastante simple una vez que lo dominas (mira los documentos API generados por epydoc para obtener la información más actualizada). Buildbot facilita la definición de tareas que no son de prueba y distribuye los probadores. Sin embargo, realmente no tiene el concepto de pruebas individuales, solo texto, HTML y salida de resumen, por lo que si desea tener una salida de prueba navegable de varios niveles, tendrá que construirla usted mismo, o simplemente usar Hudson.

Hudson tiene un excelente apoyo para profundizar en los resultados generales en suites de pruebas y pruebas individuales; también es ideal para comparar resultados 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 escamosos entre el maestro y los esclavos.

Entonces, para obtener los beneficios de ambas herramientas, ejecutamos una única instancia de Hudson, que detecta las fallas de prueba comunes, luego hacemos una regresión multiplataforma con Buildbot.

Aquí están nuestras instancias:

Ejecutamos Buildbot - Trac en el trabajo. No lo he usado demasiado ya que mi base de código aún no es parte del ciclo de lanzamiento. Pero ejecutamos las pruebas en diferentes entornos (OSX / Linux / Win) y envía correos electrónicos, y está escrito en Python.