Manifiesto de IC

La integración continua es un proceso y un flujo de trabajo desarrollador/empaquetador. La entrega continua es un proceso de lanzamiento y flujo de trabajo.

La integración continua tiene como objetivo garantizar que los cambios interrumpidos no afecten a otros desarrolladores, empaquetadores, encargados de mantenimiento o usuarios. La entrega continua tiene como objetivo que los cambios rotos no se entreguen ni se publiquen.

La integración continua nos permite corregir rápidamente el rumbo mientras desarrollamos software hacia un objetivo en movimiento. Los comentarios que la integración continua proporciona son vitales para una entrega ágil y rápida de software. Las pruebas tardías, mucho después de que se produce un cambio, no avanzan al ritmo de Fedora.

Como hay diversos esfuerzos de Integración Continua, necesitamos establecer las reglas básicas para asegurar que estamos jugando el mismo juego. Cuando llamamos “fútbol” a un juego necesitamos ponernos de acuerdo sobre lo que eso significa. Es posible que tengamos diferentes marcos, implementaciones o pruebas, pero necesitamos jugar el mismo juego.

La Definición

No puedes llamarlo “Integración Continua” a menos que…​

  1. Lo ensamble como en producción y lo pruebe como un usuario. Esto es Integración.

  2. Haga estas pruebas de integración para cada sencillo "cambio". Esto es Continua.

Sin estos pueden ser “pruebas de unidad”, “pruebas de aceptación”, “pruebas de regresión”, “garantía de calidad”, u otros pasos en el proceso … pero no es “integración continua”. Incluso podría volver a ejecutar las mismas pruebas otra vez más adelante como parte de uno de estos procesos de prueba.

Construir un componente, componerlo con otros, ensamblarlo dentro de un sistema similar al de producción, es todo parte de la integración. Una “corriente de cambio” es como nos referimos sobre los que actúa continuamente la integración. Un desarrollador es alguien que instiga y/o implementa el cambio y es nuestro objetivo para los comentarios desde las pruebas. En Fedora esto es un empaquetador o mantenedor. Generalmente aplicamos esa integración a un flujo de cambios de software pero en otras ocasiones se trata de un cambio de hardware u otros cambios.

La entrega continua consiste en tomar alguna de esas integraciones con éxito y entregarlas.

El Manifiesto

  1. Una prueba tiene valor cero hasta que el resultado afecta al comportamiento de un observador.

  2. El mejor observador para el resultado de una prueba es el desarrollador o el empaquetador que ha instigado y/o iniciado el cambio que está siendo integrado.

  3. El beneficio de la integración continua es inversamente proporcional al tamaño del cambio. Muchos pequeños cambios iterativos superan con creces un cambio masivo en paquete.

  4. Los comentarios rápidos al desarrollador o empaquetador del cambio causarán que presten atención. Intente dedicar horas, no días, para proporcionar el resultado de las pruebas.

  5. Los empaquetadores solo tiene responsabilidad de las pruebas en las que pueden contribuir.

  6. Los empaquetadores respetan las pruebas y los sistemas de pruebas que producen resultados fiables. Por el contrario ignoras y evitan las pruebas y los sistemas que son deficientes.

  7. Los empaquetadores no deberían buscar los resultados de las pruebas fuera de su flujo de trabajo.

  8. Los empaquetadores deberían ser capaces de ejecutar pruebas individuales en sus propias máquinas.

  9. La prueba ideal se puede actualizar al mismo tiempo que los cambios que se están probando. Intente almacenar una prueba junto con el software con el que está relacionada.

  10. El mejor lugar para probar un cambio es antes de que afecte a alguien más.

  11. Un pequeño conjunto de pruebas que siga estos principios es más valioso para la integración continua que un gran conjunto de pruebas que no los sigan.

Las Reglas

La Integración Continua se vuelve autosostenible siguiendo dos reglas básicas…

Para ampliar nuestro esfuerzo de IC, debemos hacerlo autosostenible. Esto no es tan difícil. Estas reglas básicos son los requisitos para construir un ciclo autosostenible donde las pruebas crezcan en lugar de pudrirse.

1. Las pruebas deben ser modificables por las personas que realizan el cambio de software

Los desarrolladores y los empaquetadores deben ser capaces de aportar cambios a las pruebas y ejecutarlas. Las pruebas llegan a ser responsabilidad de los empaquetadores y del ciclo de empaquetamiento. Es posible empezar con un pequeño corpus de prueba que cumplan este requisito. Este pequeños corpus eventualmente superará cualquier prueba “que no sea de Código Abierto”.

Razón:Las pruebas reproducibles y de código abierto permiten a los desarrolladores y empaquetadores contribuir, corregir pruebas sin actualizar y hacer crecer los conjuntos de pruebas. Debe poner atención a las pruebas y mantenerlas.

2. Comentarios Rápidos a la Persona que hace un Cambio

El desarrollador o empaquetador que hace un cambio en un paquete o un contenedor necesita tener comentarios rápidos de la integración continua. El cambio no se debería llevar adelante hasta que esa persona reaccione a los resultados de los fallos de integración.

Razón: Los comentarios rápidos originan que los desarrolladores y empaquetadores…​

  1. pongan atención a las pruebas

  2. corrijan los problemas mientras los cambios están frescos en su mente y

  3. lleve el cambio a las pruebas.

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