Fedora CI

Portal de Integración Continua de Fedora

Por qué

Visión

Hay miles de paquetes los cuales componen el Sistema Operativo. Asegurarse de que todos trabajan juntos en su conjunto no es una tarea fácil. Esto se complica aún más a medida que aumenta el número de paquetes y sus interdependencias. Antes de lanzar una nueva versión del sistema operativo es necesario realizar pruebas exhaustivas para garantizar que es lo suficientemente estable. Eso es el pasado.

Imagine un Sistema operativo Always Ready el cual consiste en paquetes que se mantienen constantemente en buen estado. Integrado y estable gracias a una amplia cobertura de pruebas que se ejecuta continuamente ante cambios en paquetes individuales, lo que permite preparar una versión nueva en mucho menos tiempo, o incluso en nada.

Imagina una distribución de sistema operativo que pudieras lanzar en cualquier momento. Esto es donde nos dirigimos. Aquí viene el IC, Integración Continua, como una herramienta invaluable para asegurar que todo está funcionando en conjunto como se esperaba en cada punto del tiempo.

Declaración

El objetivo de la integración continua es garantizar que los cambios defectuosos se descubran lo antes posible y no afecten a otros desarrolladores, empaquetadores, mantenedores o usuarios. La retroalimentación que proporciona la integración continua es esencial para la entrega ágil y acelerada de software. Las pruebas tardías, mucho después de que se haya producido un cambio, no se adaptan al ritmo de Fedora. Conozca los objetivos, la terminología y las reglas para un IC funcional en el Manifiesto.

Cómo

Hay tres piezas principales en el puzzle para que esto funcione bien: Un proceso que defina claramente cómo descubrir y ejecutar pruebas, un conjunto de herramientas que ayuden a implementar el proceso de forma eficiente y las propias pruebas.

Proceso

Activación de Pruebas

Las pruebas pueden activarse utilizando la Especificación de Metadatos de Test implementada por la [Herramienta de Gestión de Test] que proporciona una serie de características para trabajar eficientemente con las pruebas y ahora es la forma recomendada. La Interfaz de Pruebas Estándar sigue siendo compatible, pero ha quedado obsoleta.

Portón

Si una prueba falla, CI puede evitar que el cambio roto afecte a otros paquetes. Este gating se realiza en Bodhi. Greenwave se utiliza en combinación con ResultsDB y WaiverDB para tomar la decisión de gating.

  • Gating … cómo activar el gating, renunciando a las instrucciones

  • Bodhi …​ Sistema de actualizaciones de Fedora

  • Greenwave …​ servicio para evaluar las políticas de compuerta en base a los resultados de las pruebas

  • ResultsDB …​ motor de almacenamiento de resultados

  • WaiverDB …​ servicio para registrar exenciones contra resultados de las pruebas

Notificaciones

Notificaciones Fedora ha sido ajustado para notificar por defecto a cada empaquetador cuando cualquier paso de la cadena IC falle en uno de los paquetes que mantienen. Así que si usted es un mantenedor del kernel y un commit hecho al repositorio dist-git del kernel falla al componer un OSTree, FMN le notificará de ello.

Bodhi incluye los resultados de IC en su página actualizada, tan solo como ya incluye pruebas desde taskotron.

Mensajes

Varias herramientas involucradas en la automatización IC están enviando actualizaciones sobre el progreso de las pruebas al bus de mensajes. El formato coherente de los mensajes de IC permite crear servicios más sencillos que proporcionarán funciones útiles para todos.

Herramientas

Herramienta de Gestión de Pruebas

La herramienta tmt proporciona una forma sencilla de trabajar con pruebas. Puede crear cómodamente nuevas pruebas, ejecutarlas de forma segura y sencilla en diferentes entornos, revisar los resultados de las pruebas, depurar el código de prueba y activar las pruebas en el IC mediante una configuración coherente y concisa.

Roles de Prueba Estándar

Se implementaron roles de prueba estándar para permitir tanto a las herramientas de automatización como a los desarrolladores en sus entornos locales ejecutar pruebas fácilmente. Este conjunto de roles ansible soporta varios frameworks y permite ejecutar pruebas contra diferentes sujetos de prueba (como paquete rpm clásico, contenedor docker o Atomic Host). Los roles de prueba estándar han quedado obsoletos por la [Herramienta de Gestión de Test].

Marcos de Trabajo

Como la Interfaz de Pruebas Estándar no define el marco de pruebas que debe utilizarse para las pruebas, es posible elegir el marco más adecuado para su proyecto. He aquí algunos ejemplos:

Conducto

El Conducto de pruebas detecta las pruebas de los paquetes habilitados, ejecuta la cobertura de las pruebas y recopila los resultados.

Pagure

Los resultados de las pruebas del proceso IC se exhiben en la interfaz web Pagure. Consulte las páginas de solicitud commits y pull de cada paquete para ver los resultados. La integración de Pagure con COPR proporciona auto-recompilación y solicita/commit pull indicanto en los cambios nuevos.

Pruebas

El núcleo del logro del IC son pruebas fiables de buena calidad, bien seleccionadas, estables, organizadas y mantenidas continuamente.

Tipos de Pruebas

En general, tiene sentido almacenar las pruebas lo más cerca posible del flujo ascendente. Entonces, ¿cuáles son los tipos de pruebas adecuados recomendados para probar el Sistema Operativo Siempre Preparado?

  • Pruebas de funcionalidad básicas

  • Pruebas de integración

Para las pruebas unitarias usualmente tiene más sentido almacenarlas directamente dentro del repositorio del proyecto. Sin embargo, en algunos casos puede valer la pena obtener las pruebas para Fedora IC también desde el repositorio upstream.

Código de prueba

El código de prueba puede almacenarse directamente en dist-git o extraerse de otro repositorio. La configuración mínima para habilitar una prueba de humo simple se parece a esto:

execute:
    script: tal --version

Pruebas desde un repositorio compartido puede estar activado de esta manera:

discover:
    how: fmf
    url: https://src.fedoraproject.org/tests/shell
execute:
    how: tmt

Consulte la documentación de la Herramienta de Gestión de Pruebas para más detalles y ejemplos.

Ejecución de Test

Ejecutar pruebas es tan sencillo como ejecutar una única instrucción:

tmt run

Aprenda más en la sección Ejecutar pruebas.

Responsabilidad Compartida

La propiedad y el mantenimiento de las pruebas deben ser compartidos entre QE y Devel. Para las pruebas que residen en el espacio de nombres rpm, QE puede utilizar pull requests para crear/actualizar pruebas. Del mismo modo, en el espacio de nombres de las pruebas, tanto QE como Devel tendrán derechos de confirmación, tanto QE como Devel deben revisar y aprobar cada confirmación.

Más

Contacto

Si tiene preguntas o le gustaría involucrarse:

Enlaces

Adicionalmente aquí hay algunos enlaces relacionados:

Want to help? Learn how to contribute to Fedora Docs ›